Re: [Cfrg] [SSH] [TLS] 3DES diediedie

[David Jacobson <[e-mail]>]

On 8/25/16 3:38 PM, denis bider (Bitvise) wrote:
> In SSH, 3des-ctr is currently a cipher in good standing (RFC 4344). 
> CBC is already discouraged (and alerted by many security scanners) 
> because of the issue of naive decryption of packet lengths in this mode.
> I might be mistaken, but I do not see applicability of this issue in 
> CTR mode. If two ciphertext blocks collide, I don’t see how one could 
> take advantage even if one knows the plaintext corresponding to one of 
> the blocks. If one knows a lot of the plaintext, and therefore finds 
> two key-stream blocks that collide, I’m not seeing what use that could 
> be, either.
With any block cipher in CTR mode there would be no collisions until the 
counter had wrapped around to the starting value.  Thus for 3DES with a 
full-width counter, there are no collisions until 2^64 + 1 blocks have 
been processed.

Ironically, the limitation to 2^32 blocks is not because of the 
possibility of a collision, but because of the the impossibility of 
collisions.  Collisions would be expected beginning around 2^32 blocks, 
but in 3DES CTR mode with a full width counter, they won't be any 
through 2^64 and thus the keystream can be distinguished from random.

     --David Jacobson

> In addition, SSH has an automatic re-key that is initiated by both 
> clients and servers after every 1 GB of data transferred (128k blocks) 
> in either direction, or every hour, whichever comes first. Most SSH 
> implementations, except rare broken ones that I rarely hear of, either 
> initiate key re-exchange themselves, or support it when it is 
> initiated by the other party. Key re-exchange replaces both encryption 
> keys and the initial IVs in both directions. This also makes attacks 
> against 3des-cbc more difficult.
> Correct me if I’m wrong, but I don’t see that any action needs to be 
> taken in SSH against 3des-ctr, whereas CBC mode is defended by key 
> re-exchange (with 128k blocks, collision probability less than 1 in 1 
> billion), and is itself already discouraged.
> denis
> *From:* Blumenthal, Uri - 0553 - MITLL <mailto:[e-mail]>
> *Sent:* Thursday, August 25, 2016 09:56
> *To:* Tony Arcieri <mailto:[e-mail]> ; Peter Gutmann 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [Cfrg] [TLS] 3DES diediedie
> >>  An attack that recovers cookie if you can record 785GB of traffic 
> isn't anything I'm losing any sleep over.
> >
> > ..but is not a terribly dissimilar traffic volume to recover 
> plaintexts from similar attacks against RC4,
> > which received "diediedie" in RFC7465.
> >
> > Perhaps notable is the RC4 attacks work across multiple session 
> keys, whereas SWEET32 requires the same key,
> > but I think the practical consequences regarding data volume limits 
> are similar.
> I think this difference is crucial, because when the majority of the 
> traffic was RC4, then scourging a lot of it and getting at least one 
> key out of the attack seemed bad enough to do something about it. 
> Hence RFC7465.
> With 3DES, you need that much of traffic protected by the key you’re 
> trying to attack. This completely removes any notion of practicality. 
> I’m not losing my sleep over this either, and think this situation 
> does not justify “diediedie”.
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg