[Cryptography] On the Impending Crypto Monoculture

Andrew Donoho awd at ddg.com
Sat Mar 26 15:03:30 EDT 2016


> On Mar 25, 2016, at 20:41 , Ray Dillinger <bear at sonic.net> wrote:
> 
> Ergh.  I babbled, of course. The first sentence above is just
> plain wrong. Parts of the rest are muddled. Let me clarify.



Bear,



	Thank you.



> Briefly:  The misattribution attack on Mac-Then-Encrypt allows
> Bob to redirect messages originally sent to Bob (because he can
> decrypt those, then replace the MAC, re-encrypt, and resend them).
> In security terms this is a pothole.  It can be harmful if Alice
> is sending to Bob anything Bob should not be able to produce
> himself, but is otherwise harmless.



	OK. As I am currently architecting an expanded system similar to Spot’s, I will incorporate your insight into that process. As Encrypt-then-MAC follows the similar pattern as a publicly validate-able digital signature, I have a bias towards building the storage system around similar patterns, Encrypt-then-MAC and Encrypt-then-Sign.



> The misattribution attack on Encrypt-Then-Mac allows Bob (or
> Mallory) to intercept an encrypted message from anybody to
> anybody, and with no need to decrypt it substitute his own
> MAC for the original.  In security terms this is a missing
> bridge.  You have to find a different way to get where you're
> going.  This is the good reason why Encrypt-Then-MAC ought
> to be avoided.
> 
> In the Encrypt-then-MAC world attackers can substitute MACs
> on messages regardless of whether they can decrypt them -
> With a lot of protocols it's a pretty easy guess what's being
> said, so inability to decrypt is frequently inadequate defense.



	My “protocol" is really a set of cloud database tables to which access is mediated by my lambda functions. I leave it up to AWS’s mobile hub to securely connect to those functions. AWS appears to use SSL encrypted REST connections to invoke lambda functions. In general, if Mallory makes the data invalid, that is an unfortunate but acceptable answer. My service is all about maintaining cloud stored data integrity and privacy.




	My current biggest issue is determining which of the maze of twisty little IETF standards, all alike, to invoke to wrap and encrypt my BLOB AES key. I believe RFC-5652, Cryptographic Message Syntax (CMS), and the DER wrapper called KeyTransRecipientInfo is the winner. As a result of this "discovery process,” I think a little bit of pruning and cultural diversity discrimination in these IETF standards is probably warranted. Supporting requirements from the past, when we understood the problems less well, is always a challenge. As protocols are forever, deprecation is a different challenge. But I believe the IETF must rise to it. I don’t think it is appropriate though to reject the Suite B algorithms in favor of the Bernstein stack. I can see the reasons to want to support a non-U.S. Government sourced stack. Hence, I would expect everyone is going to end up with a duo-culture.



Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd at DDG.com, +1 (512) 750-7596, twitter.com/adonoho

New: Spot marks the taX™ App, <http://SpotMarksTheTaX.com>
Retweever Family: <http://Image.Retweever.com>, <http://Retweever.com>

"To take no detours from the high road of reason and social responsibility."
   -- Marcus Aurelius



More information about the cryptography mailing list