Reputation
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
1 8 21
Newest
 Pundit
Impact
~59k people reached

Feb
4
comment Secure randomized data matching?
crypto.stackexchange.com/q/9183/991 ​ ​
Feb
4
revised How can one securely hash passwords server side while avoiding DoS?
fixed title's grammar
Feb
3
comment Block cipher not resistant to collisions
Solve f2(x,y) = z ​ ​
Feb
3
comment Extension of Diffie Hellman for many participants
It's also a noun phrase, rather than a question. ​ ​
Feb
3
comment Block cipher not resistant to collisions
What have you tried? ​ ​
Feb
3
comment How does a non-prime modulus for Diffie-Hellman allow for a backdoor?
Has that modulus been publicly factored? ​ ​
Feb
2
comment When we use one time pad TWICE in two different ways
Yes. ​ The adversary can just solve the system. ​ ​ ​ ​
Jan
31
comment Exactly how bad is using 'mod' to clamp reduce numbers to a given range?
... "than" what one-half you talked about? ​ (I only see a mention of "a factor of 2".) ​ For example, if you used that as the keystream for a stream cipher, then an eavesdropper could easily distinguish between [encryptions of long mostly-0 plaintexts] and [encryptions of long mostly-1 plaintexts]. ​ ​ ​ ​
Jan
31
comment Exactly how bad is using 'mod' to clamp reduce numbers to a given range?
If m=2 and n=3, then using the simple method on true randomness would have a 2/3 probability of outputting 0 and a 1/3 probability of outputting 1. ​ (That differs by 1/6 from the uniform distribution on {0,1}.) ​ ​ ​ ​
Jan
31
comment Exactly how bad is using 'mod' to clamp reduce numbers to a given range?
"the problem here" is that you've assumed m <= n but nothing else about m and n. ​ ​
Jan
31
comment Exactly how bad is using 'mod' to clamp reduce numbers to a given range?
@squeamishossifrage : ​ The distinguishing advantage increases by less than m/(2$\hspace{-0.02 in}\cdot$n), so it'll also be secure when that is negligible. ​ ​ ​ ​
Jan
31
comment Is this a good communication scheme?
I edited my answer and replied in chat again. ​ ​
Jan
31
revised Is this a good communication scheme?
made message_number no longer only count those with high-level plaintext
Jan
30
revised Is this a good communication scheme?
changed answer to address new protocol
Jan
28
revised Why doesn't Morse Code try to achieve more compression?
improved grammar
Jan
28
comment Is this a good communication scheme?
Also, your revision does not affect the identity misbinding attack. ​ ​
Jan
28
comment Is this a good communication scheme?
The authentication would "be fixed with a challenge and response system mixed into the handshake protocol", since something "mixed into the handshake protocol" would use an independent symmetric key, rather than the MACKey that the key agreement protocol will output. ​ I now realize that even in the ideal cipher model, using MACKey as you propose would directly compromise authenticity for the subsequent communications, and although each forged plaintext individually would be garbled, the xor of their initial blocks could be chosen arbitrarily. ​ ​ ​ ​
Jan
28
comment Is this a good communication scheme?
I'll get to the rest later, but regarding your last point: ​ ​ ​ That's the identity misbinding attack succeeding. ​ "the user will just be alerted that they are talking to someone new", even though the plaintexts are still coming from the same person and are not known to adversary. ​ ​ ​ ​ ​ ​ ​ ​
Jan
28
comment Is this a good communication scheme?
(... continued) ​ ​ ​ a (strong) PRP implies such security for AES$_{\text{CFB}}$, but I've made no attempt at checking that.) ​ That doesn't "protect against some attacker intercepting and replacing Alice's key with theirs", although if "their own key will not match Bob's trusted list" then that would protect against such identity misbinding. ​ Will you also be assuming that the attacker's "own key will not match" Alice's trusted list? ​ ​ ​ ​ ​ ​ ​ ​
Jan
28
comment Is this a good communication scheme?
As I edited into my answer, I'm not sure your scheme even implicitly authenticates Bob to Alice. ​ If it does, then "a challenge/response of HMAC(Nonce,MACKey) from each party after the key exchange" would constitute explicit authentication, but would require that (in addition to IND-CPA) AES$_{\text{CFB}}$ be secure against a very weak type of CCA1 attack with 2 chosen ciphertexts. ​ (It ought to be provable that AES being ​ ​ ​ (continued ...) ​ ​ ​ ​ ​ ​ ​ ​