]]>
Comment on Blake Tree Hashing by Alex Elsayed
https://codesinchaos.wordpress.com/2012/10/05/blake-tree-hashing/comment-page-1/#comment-31
Wed, 04 Dec 2013 10:55:44 +0000https://codesinchaos.wordpress.com/?p=32#comment-31Have you considered building on https://keccak.noekeon.org/sakura.html ? At very least, it would address the interleaved hashing case.
]]>
Comment on CurveCP Review – Part 1 Crypto by CodesInChaos
https://codesinchaos.wordpress.com/2012/09/09/curvecp-1/comment-page-1/#comment-30
Sat, 21 Sep 2013 19:35:26 +0000https://codesinchaos.wordpress.com/2012/09/09/curvecp-review-part-1-crypto/#comment-30In reply to Pieter Hintjens.
I didn’t find a vulnerability when everything goes well. My issue is that if a shot term key c’ gets compromised, that shouldn’t have any long term consequences. In particular the attacker who learns c’ should not be able to authenticate as C in a new connection.
That paragraph started with:
> If an attacker learns client short term secret c’ of a single session
of course that shouldn’t happen and it’s thus not a severe problem. But it’s still an unnecessary risk that a better protocol can avoid.
]]>
Comment on CurveCP Review – Part 1 Crypto by Pieter Hintjens
https://codesinchaos.wordpress.com/2012/09/09/curvecp-1/comment-page-1/#comment-29
Sat, 21 Sep 2013 09:37:03 +0000https://codesinchaos.wordpress.com/2012/09/09/curvecp-review-part-1-crypto/#comment-29Thanks for this review of CurveCP. I’m looking at changing CurveZMQ per your recommendations for client authentication but there is one thing I don’t understand. You say that an attacker can get the vouch and resend it, to impersonate the client in the future. However, the vouch is sent inside Box [C + vouch](C’->S’), so only the server can read the vouch. An attacker would also need the server’s temporary secret key, which is surely not happening.
How does an attacker get the vouch in your analysis?
