[Cryptography] AEAD modes for signed ciphertext

[ianG]

lots of snipping,

On 11/05/2015 22:45 pm, Ned Ulbricht wrote:

> Sub-part 2A: Userids for principals
>
> In part 1 above, I referred to senders and receivers by their "tofu
> tags" (alice at foo.example and bob at bar.example).  Those are what end users
> see.  The cryptosystem internally identifies principals by hashes of
> their long-term public signature keys.  A directory server certifies
> that a "tofu tag" in its domain maps to a public signature key hash, at
> the time when the directory is queried. Following that initial query,
> the cryptosystem stores and uses the hash as a userid.


( This is what we call "squaring Zooko's triangle".  You can google on 
ZT which basically describes why it is that cryptographic ids don't work 
for humans.  The challenge is to build a composite system that provides 
users what they want, and to link that downwards into the keys.  Also 
you might want to check out petnames, and capabilities in general. )


> The mis-match between the human-readable "tofu tag" seen in an
> end-user's address book, and userids internal to the cryptosystem may
> cause the end-user to fail to grasp the security guaranteed by the
> cryptosystem--as well as the security NOT guaranteed.  While no effort
> is made to hide userids, in practice, the chance that users will
> understand, compare or exchange their userids ranges from slim to
> laughably absurd.


( OK, so this is what I call the 'introduction problem' - how it is that 
Alice's agent is introduced to Bob's agent such that, post-introduction, 
when the former sees the latter, it alerts Alice to her petname for Bob. )


...
> Part 3: Signature substitution attack
>
> The cryptosystem that I have partially sketched out in part 2 above, is
> vulnerable to a classic signature substitution attack.
>
> Suppose that Mallory (mallory at baz.example) is another one of Bob's
> authorized senders. If Mallory obtains one of Alice's messages to Bob,
> then Mallory may strip off Alice's signature, and create his own
> signature for that message, even though he is unable to read the
> encrypted ciphertext.  Bob will then accept Alice's message as one
> generated by Mallory.
>
> In short, the outer message signature may guarantee authorization, but
> fails at authenticity.


Yup.  Now, as you've handwaved about how Mallory acquires Alice's 
messages, we have to assume for the attack that Mallory can read any of 
Alice's messages and do the same.

Which then implies that any message cannot be self-authenticating.  So 
now we need to examine how authentication is done.  It's done by the 
signature.

What is going on here then is that you are allowing the signature to be 
replaced (easy) but the user is not informed.  Therefore this is not a 
cryptographic issue but a UI issue.  Your user has to be informed of who 
signed the message, and it this is bungled then ... your attack succeeds.

(This problem is the same problem existing in the browsers where the 
precise "who said what" is not clear, leading to phishing, and also with 
S/MIME, where the implementations bungle it by insisting that the outer 
envelope's sender in cleartext matches the cryptographic signer, simply 
because it isn't providing a proper UI that shows who signed the message.)

So, how are you informing Bob that the message came from Alice?  Or 
Mallory?  The "answer" in short is to make it obvious.


> It gets worse.  After Mallory has stripped off Alice's outer signature,
> he may alter the ciphertext or associated data before creating his own
> outer signature.  That might provide a springboard for other attacks.
> Thus, in some sense, the outer signature also fails to assure message
> integrity.


Right.  Ad infinitum.  Which indicates actually ... any message can be 
sent by anyone, and Bob isn't noticing who they come from.


> Note that I'm handwaving just a little bit over exactly how Mallory
> intercepts Alice's message to Bob.  Recall that I have only partially
> sketched out "the" cryptosystem, and there do actually happen to be
> other, unmentioned cryptographic barriers for interception in transit.
> Yet, after all, Mallory might be in control of Bob's relay server.


Sure.


> Part 4: Preliminary thoughts on countermeasures
>
> The simplest countermeasure for a signature substitution attack is to
> have Bob somehow recognize that the message's decrypted plaintext
> obviously was generated by Alice, and therefore Mallory's outer
> signature only indicates an attack underway.  That solution seems less
> than satisfactory, though.


It's the only solution as far as I can see.  Only Bob "knows" who Alice 
is, the software just handles the linkage and displays Bob's petname for 
Alice (etc), and doesn't handle context of what that might mean.


> My latest thinking on the problem tends towards computing a separate MAC
> (MIC) for the ciphertext and associated data.

This solves nothing, because it's just another "sig" and can be stripped 
off as well.

> This is motivated by my
> current gravitation towards AES in CBC mode as the symmetric part of the
> default confidentiality suite.


(As an aside, in 2004 or so, I did AES with CBC [0] but now that it's 
2015 I use ChaCha20/Poly1305 and I will use CAESAR when it comes out, or 
SHA3 if it holds to its promise, when either of these come out.)


> My previous thinking considered automated validation of decrypted
> plaintext as a very desirable feature.  Thus, solutions as simple as...
> never mind. I could go on for pages, but I'll stop right here.


Yep.  But Mallory can craft any email, including "I AM ALICE."  Tech 
can't stop that.  It can only show the true source of the message.

(Consider this possibility.  Alice sits next to Mallory in the HQ. 
Alice's comset breaks.  She needs to get the message "withdraw 
immediately" to Bob, or else all is lost.  So she asks Mallory to send 
the message "withdraw immediately, THIS IS ALICE" to Bob.  If she can't 
do that, she'll consider the system broken, and Bob will be surrounded 
and killed...)



Others may differ in opinions, but I think your problem is a UI problem. 
  And your task is to integrate into the security UI of the system.



iang


[0] http://www.webfunds.org/guide/sdp/sdp1.html