Reputation
335
Next privilege 350 Rep.
Access review queues
Badges
1 10
Newest
 Yearling
Impact
~14k people reached

  • 0 posts edited
  • 2 helpful flags
  • 111 votes cast
May
4
comment PGP digital signature vs SHA256 HMAC Comparison
@mikeazo - loading the key and then validating it will fail the most basic tests. That's assuming you validate your crypto parameters before using them. GPG stopped providing the factorization in version 1.4.1 from July, 2005. Apparently, no one used it (kinda scary, hugh...).
May
4
revised PGP digital signature vs SHA256 HMAC Comparison
Added info on crypto attacks.
May
4
answered PGP digital signature vs SHA256 HMAC Comparison
May
4
comment DH and PKI for KeyExchange
You might consider taking a look at the papers Multicast Security: A Taxonomy and Some Efficient Constructions and Provably Authenticated Group Diffie-Hellman Key Exchange. Or more generally, Multicast Encryption. Multicast Encryption and Broadcast Encryption have been discussed here on Crypto.SE.
May
4
comment The difference between MAC algorithms and what to use
"It is recommended to use a separate key for the HMAC but you may get away with using the same key as used for encryption..." - Maarten, the HAC specifically warns against this. See the discussion around page 367. According to Menezes (et al): using the same key to both encrypt the data and authenticate the data (which would allow a single pass over the data) causes the ciphertext to be independent of the plaintext. So the authentication mechanism is rendered completely insecure.
May
4
comment RFC 5297 implementation
Software Recommendations Stack Exchange might be a better place to ask.
May
4
comment Can I submit an encrypted message to see if its breakable here?
See What topics can I ask about here? in the Help Center. Also see Programming Puzzles & Code Golf Stack Exchange, and Usenet's rec.puzzles.
May
4
revised Should we sign-then-encrypt, or encrypt-then-sign?
Added links and cross references.
May
4
comment Should we sign-then-encrypt, or encrypt-then-sign?
@Ricky - Perhaps you should read Shoup's paper and comments on why he insists on adding parameters that others consider optional (here, "others" is like the folks at the IEEE and the P1363 standard). You might also take a look at Crypto++'s implementation, and trace the code surrounding DHAES_MODE.
May
4
revised Should we sign-then-encrypt, or encrypt-then-sign?
Added info on Data Authentication versus Entity Authentication.
May
4
comment Should we sign-then-encrypt, or encrypt-then-sign?
@Ricky - No. The R in an IES is effectively half of a Diffie-Hellman exchange (DH or ECDH); and not a simple key wrap. To arrive at the shared secret, the recipient performs the other half of the key exchange. The shared secret is then digested and used to derive a symmetric cipher key and mac key. To break the scheme, an attacker would need to solve the Diffie-Hellman problem.
May
4
revised Should we sign-then-encrypt, or encrypt-then-sign?
Added link to Krawczyk's paper.
May
4
comment Should we sign-then-encrypt, or encrypt-then-sign?
@Ricky - the public key cryptography is used in the KEM. Perhaps you should read up on the scheme and then we can talk about it.
May
4
comment Should we sign-then-encrypt, or encrypt-then-sign?
@Ricky - the public key cryptography is used in the KEM, not the MAC/Signature.
May
4
revised Should we sign-then-encrypt, or encrypt-then-sign?
Added links to libraries.
May
4
answered Should we sign-then-encrypt, or encrypt-then-sign?
Apr
27
comment Is this variant of SRP useful?
When you changed the use case, you changed the threat model (from peer-to-peer app to logic controller). If you are using a low-resource device, like a smart card or PLC controller, you probably can't do Diffie-Hellman anyway. You'll likely be using PSK, and not SRP.
Apr
27
comment Is this variant of SRP useful?
SRP provides mutual authentication and channel binding. Since you don't have a server, you don't suffer the Unattended Key Storage problem. That is, you have interactive users on both sides of the channel. And you don't have a collection of passwords to protect like in a traditional client-server architecture. The verifiers address the threats to the password in storage on the server side.
Apr
27
comment Is this variant of SRP useful?
If this were my problem (and in the absence of your research into it), I would use the protocol described as 6a in TLS. I would make the "initiator" the "client", and the "recipient" the "server" and have the server calculate and use the verifier. It may cause an extra exponentiation or an extra message on the wire. But that accounts for little in the grand scheme of things in a peer-to-peer app.
Apr
27
comment Is this variant of SRP useful?
The verifier is effectively the salted hash in traditional client/server systems. But rather than using a salted hash, the verifier is an equivalence class in the field based on exponentiation. The verifier exists because of the added pressures of password storage on the server. That is, the verifier makes it hard to recover the password. In the absence of client/server and the password storage problem on the server, it should be acceptable to allow both sides to use the password directly. Apparently, Thomas and Stanford had this insight.