29,875 reputation
12359
bio website
location
age
visits member for 3 years
seen 7 hours ago

Aug
28
comment RSA was rejected by which journal?
The site is, at best, questionable. For one, Dijkstra's "Go to statements considered harmful" was a letter to the CACM, not a paper. I don't believe there were formal reviews of letters to the editor.
Aug
27
comment What's the point of a Meet In The Middle attack using i.e. double AES with throw-away keys?
@maincodebase: not quite any such attack; if the attacker has enough partial information to limit the number of potential messages to a small bound, as in "The first letter of my password is X", then an AON transform won't help you. On the other hand, we have ciphers that are immune to known plaintext (and chosen plaintext) attacks; hence we don't worry too much about how we might work with a cipher that isn't.
Aug
26
comment why should one use lattice-based systems in epassports in post- quantum computers era?
You might want to try to reword your question to state more clearly what you are asking. I tried to edit your question, however I gave up trying to figure out what you are asking. Is it just "why can't we use lattice based systems in epassports", or was it something more?
Aug
25
comment Found a way to crack AES-128, what now?
@hunter: it would count as a break even if he could not decrypt a single ciphertext; it would count as an extremely bad break even if he needed a few gigabytes of chosen plaintext.
Aug
25
comment Solution with high decryption cost and low encryption cost
@otus: I don't know why we'd want to slow down the decryptor either; however I believe that's what devd asked for...
Aug
25
comment Solution with high decryption cost and low encryption cost
@otus: If you are saying "he can decrypt multiple messages quickly", well, no, that's why I stir in $S$ (a nonce) into the puzzle that hides $r_i$; different messages will have different $S$ values. If you're saying "he can then test multiple values of $Key$ quickly", I didn't believe that was an issue; $Key$ is (say) a 128 bit value (and hence is immune from brute force search). $Key$ is present solely in case we want to forbid a third party from decrypting at all. If that is not a requirement, $Key$ can be omitted.
Aug
25
comment Efficiently map $2^n$ unique 64-bit vectors to $2^n$ $n$-bit vectors where $n < 64$?
I'll vote to close as well; but you might want to consider: "what properties do you want from your mapping?" If you want just any mapping, just chopping off $64-n$ bits off the vectors works fine -- is there a reason why that isn't sufficient?
Aug
24
comment Simple proof that shows AES is not a uniform permutation on any n-bit string?
@ddddavidee: actually, there are block ciphers that can implement an odd permutation; they're not common, but they most certainly do exist. AES (as well as the vast majority of block ciphers) will always do an even permutation.
Aug
21
comment CBC-MAC key can be added to ciphertext?
@Kingland: yes (or somehow otherwise have both sides arrive at the same secret keys)
Aug
20
comment Regular MACs vs Carter-Wegman MAC
@CodesInChaos: some CW MACs are more tolerant about nonce reuse. It all depends on the crypto part that takes the output of the universal hash, and disguises it. Earlier CW MACs did a hash over the universal hash and the nonce; nonce reuse would tell the attacker little (unless the universal hash output was also the same -- a low probability event by the definition of universal hash). Modern CW MACs tend to use the universal hash output xor'ed with an encrypted form of the nonce -- that's a lot dicier with nonce reuse.
Aug
20
comment Recover plaintext from truncated ciphertext using AES for FPE
Yes, changing the AES key round would suffice, but (IMHO) is more heavy weight than you need. Instead, I would suggest you put the round index into the (currently zero) padding you use to pad out the 32-bit into a full 128 bits.
Aug
20
comment Recover plaintext from truncated ciphertext using AES for FPE
Two comments: for a Feistel cipher, you need to make each round function different (say, stir in the round index as an input to AES); otherwise, you open yourself up to slide attacks. Also, step 5 says "if the ciphertext is not in range, keep on doing Feistel until it is". Actually, to be able to decrypt unambiguously, you need to rerun the entire encryption procedure (including all 7 rounds).
Aug
16
comment How does RSA signature verification work?
@rubo77: it's not just computing the e'th root of P, and then taking that modulo N. Instead, you're trying to find the value X such that $X^e \bmod N = P$.
Aug
15
comment Can you fake messages from recorded message-history?
Sorry, but the cryptographer in me cringes when I hear someone saying "encrypt with the private key". You can do that with RSA; however, that doesn't work with just about any other public key algorithm. Instead, it is more useful to talk about signing the message (and that's what we generally actually do with RSA in any case).
Aug
15
comment How does RSA signature verification work?
@rubo77: you could, if you knew the factorization of $N$. If you don't, well, that's a hard problem (and, in fact, is known as the RSA problem).
Aug
14
comment Decrypting an Affine Cipher with known characters
Actually, the equations are mod 26; however there still isn't any solution for the three cited.
Aug
12
comment Is XORing a SHA256 better than truncating it?
Now, the question I dup'ed this two doesn't talk about xor'ing the two halves; however it's the same as the other two. However, you talk about "minimize the probability of a collision"; who's generating the images? Is it someone deliberately trying to create a collision? If so, then if he also has significant amount of computational resources, he can create a collision in any of the three methods (with Pollard Rho and computing circa $2^{64}$ hashes).
Aug
12
comment Is XORing a SHA256 better than truncating it?
It might be reasonable if you would include what security properties you expect from the truncated hash. I don't know if that would change which one is best; however, depending on what security properties you expect, it may be that none of them would meet that goal.
Aug
12
comment How does recovering the public key from an ECDSA signature work?
@JanMoritzLindemann: it appears that the link you gave got it a bit off; you iterate from the values between j=0 and j=h-1; if h=1, that means you need consider only j=0
Aug
12
comment How does recovering the public key from an ECDSA signature work?
@JanMoritzLindemann: I had written it assuming you were in a curve with cofactor 1 (h=1). If you are working with a curve with a larger cofactor, then, yes, you need to iterate through the possible multiples of the cofactor, and reject any point $R$ that isn't a multiple of $G$ -- the link you gave explains how to do that.