meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 7 hours ago | |
| stats | profile views | 105 |
|
Apr 11 |
reviewed | Approve suggested edit on Any point in waiting for the SHA-3 standard? |
|
Apr 10 |
comment |
What does “adaptively secure” mean? @PaŭloEbermann: absolutely. I mentioned chosen-plaintext attack because user4811 mentioned that this was in the context of a PRF. |
|
Apr 10 |
revised |
What does “adaptively secure” mean? %*&%@ typo... |
|
Apr 10 |
revised |
What does “adaptively secure” mean? Extended explination |
|
Apr 10 |
reviewed | Approve suggested edit on What does “adaptively secure” mean? |
|
Apr 10 |
answered | What does “adaptively secure” mean? |
|
Apr 10 |
reviewed | Approve suggested edit on ECKS-PS algorithm: searching in encrypted data; bilinear maps |
|
Apr 10 |
comment |
AES Message Authentication Vulnerability The obvious question is "what do they mean by the AES function()". If it's just AES in ECB mode, then yes, that should not be possible. If they mean AES in some other mode, that might be possible, depending on what that other mode was. |
|
Apr 9 |
comment |
AES+CTR+HMAC Encryption and Authentication on an Arduino Is there a specific reason you are inventing your own protocol, rather than reusing an existing one (such as TLS or SSH)? Cryptographical protocols are subtle; it's easy to make mistakes; you're better off relying on something which has already been vetted. |
|
Apr 9 |
reviewed | Approve suggested edit on Ciphers in CBC mode reveal place of change in plaintext |
|
Apr 8 |
comment |
May the problem with DES using OFB mode be generalized for all feistel ciphers @SanderDemeester: yes, as long as $k$ is not a DES weak key, then encrypting $P1$ and then encrypting $C1$ is quite unlikely (probability $2^{-63}$) to result in $P1$. Remember, OFB was originally designed with DES in mind; it is unlikely that the designers missed something this drastic. |
|
Apr 8 |
comment |
May the problem with DES using OFB mode be generalized for all feistel ciphers The assumption you based this question on is flawed (as Thomas pointed out): with DES, reencrypting the block with the same data does not result in the original plaintext (unless you use a weak key). You fixed some later text to reflect this, but your original question relies on this assumption. |
|
Apr 7 |
comment |
Do I need to know the “mode of operation” to decrypt a message encrypted with a block cipher? @hunter: encrypting the mode and the algorithm can often be guessed by an attacker (e.g. "when Alice encrypts a message, she uses AES-128 in CBC mode"), and hence keeping it secret usually doesn't add that much security. As for 'discouraging' encrypting non-sensitive data, well, that's more in the lines of 'don't make things more complex than you have to; complexity is the enemy of security' rather than 'encrypting this will actively make things less secure'. |
|
Apr 6 |
revised |
Do I need to know the “mode of operation” to decrypt a message encrypted with a block cipher? added 437 characters in body |
|
Apr 6 |
answered | Do I need to know the “mode of operation” to decrypt a message encrypted with a block cipher? |
|
Apr 6 |
answered | Is there a preferred way/standard on how to transmit an initialization vector for AES encryption |
|
Apr 5 |
comment |
DSA signatures with related k and unknown payloads @D.W.: sorry about that; I meant the DSA signature verification algorithm. |
|
Apr 5 |
comment |
DSA signatures with related k and unknown payloads Actually, it'd be more practical to check the guesses for the messages using the standard DSA signature algorithm; it takes longer than doing a Gaussian elimination; on the other hand, we don't have to check each potential pair of messages $(m_1, m_2)$, we can check each message individually. This reduces the number of tests from $10^8$ to $2 \cdot 10^4$ in your scenario, |
|
Apr 4 |
comment |
Can one have an authentic, but repudiable, message without a previously shared secret? @SmitJohnth: if you look at the original question, Paulo asked for a single message protocol where the first step was that "Bob can construct a message using ... Alice's public key." That means that Bob is assumed to somehow know Alice's public key (and know that it is, indeed, Alice's). That he knows that is indeed important; however, as far as this protocol is concerned, it is a problem that has already been somehow solved. |
|
Apr 4 |
comment |
Can one have an authentic, but repudiable, message without a previously shared secret? @SmitJohnth: actually, in this case, it does, at least it does cryptographically bind the authenticated message to the public key. In standard DH, both sides pick an ephemeral exponent, and send the public value to the other side; there is nothing inherent in the DH protocol that binds the public value to any identity (and hence that needs to be added somehow). In my proposal, the public value is the public key; a third party cannot generate a message which will authenticate. How the public key is bound to the 'identity' is out of the scope of the protocol; all PK systems have to handle it |
