[Ach] GCM in real time applications

[timo]

Thanks for te reply.

On Tue, Jun 21, 2016 at 01:16:57PM +0800, Aaron Zauner wrote:
> Hi,
> 
> Full disclosure: we (Hanno, a couple of other people and myself) are working on GCM/GHASH attacks in real world implementations. A recent result of our research can be found here: https://eprint.iacr.org/2016/475
> 
> I've put extensive effort into reading up on past research w.r.t. GCM/GHASH since December.
> 
> > On 21 Jun 2016, at 04:25, timo <timog24 at mailbox.org> wrote:
> > 
> > I recently came across this story about NSA employees messing with crypto standards regarding internet telephony.
> > Whats interesting is some details about the use of GCM in real time applications like SRTP and ssh.
> 
> This article is entirely false and makes false assumptions. I've written to the author and his security advisor back when it was published in 2014 that it should be retracted or at least corrected.
> 
> > 
> > The story is in german therefore I'm translating the relevant parts:
> > 
> > 
> > "Dieser aktuelle NSA-Entwurf betrifft das Protokoll zur Verschlüsselung von Internettelefonie. Der dafür vorgesehene Blockchiffre-Modus namens "Galois
> > Counter Mode" (GCM) aber wurde bereits 2005 von einem namhaften Kryptografie-Eperten von Microsoft als generell angreifbar bezeichnet und vernichtend
> > kritisiert. Speziell und eindringlich wurde davor gewarnt, diese Chiffre für Echtzeit-Protokolle einzusetzen, als negatives Praxisbeispiel dafür wurde
> > die Verschlüsselung von Internettelefonie angeführt."
> > 
> > [...] The "Galois Counter Mode" (GCM) was heavely criticised in 2005 by a renowned  Cryptoexpert at Microsoft and described as generally vulnerable. It
> > was warned that especially in realtime application this cipher should not be used. [...]
> 
> Ferguson's critique is specifically on GCM with short tags. These aren't employed by many protocols and difficult to exploit. TLS is certainly not one of them.

So there are no common GCM implementations with those short tags. 
Neither TLS nor SSH are affected by this then?

> 
> > 
> > and
> > 
> > "Der finnische Kryptograf Markku-Juhani Saarinen hatte 2012 auf der Sicherheitskonferenz FSE 2012 in Washington ebenfalls vor dem Einsatz der
> > Blockchiffre gewarnt. Gerade bei Echtzeitprotokollen wie Secure Shell für Virtual Private Networks sei von GCM dringend abzuraten."
> > 
> > [...] The finnish cryptoexpert Markku-Juhani Saarinen had also warned not to use the blockcipher in 2012 at the securityconferenc FSE in Washington.
> > Especially the use with realtime applications like ssh for VPN is not recommended. [...]
> 
> That's a very specific and rather theoretical attack. Saarinen notes in his paper that this isn't exploitable in any of the mentioned protocols and just gives a recommendation in that regard. I recently had a mail exchange with Saarinen on improving his (again; rather theoretical) attack.
> 
> > So my question is: Why is nobody talking about this?
> 
> Everybody is, as we note in our paper, no cryptographer (except for intel and the original designers) are really happy with GCM. But it's the best deployed choice we currently have for authenticated encryption. I have a individual draft for AES-OCB for TLS that's going to be discussed at the next IETF meeting in Berlin: https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-04 (patent issues resolved!)
> 
> > Even though it seems ok to use GCM with most https applications, it is also widely used and recommended with ssh and SRTP (like xmpp).
> 
> I'm not aware of any practical GCM related attacks on SSH nor SRTP. Neither are (very) well known cryptographers I've talked to about this issue.
> 
> > Should it not be recommended to avoid the use of GCM in these later cases?
> 
> Certainly not. The alternative you currently have in these protocols is CCM mode, which is a two-pass scheme, meaning it's performance is *very* slow compared to GCM. On intel architectures you get AESNI which speeds up AES and GCM due to instructions for multiplications of polynomials over finite fields (Google: "Intel CMUL"). On architectures that do not support these instructions you now have ChaCha20/Poly1305 as an alternative option (OpenSSH added support for that in I think late 2013 already, by now it's an IETF standard and will be available in TLS 1.2 and TLS 1.3, some implementations do already support it. Google has supported it for a couple of years now given that you're on an Android plattform and talking to their front-end servers).
> 

Or you can use good old ctr mode. Nothing against that as far as I know. 
In the end performance isn't the most important thing with ssh 
connections. Thats rather something I worry about with TLS.

BTW. chacha20/poly1305 is now also available in firefox. 

> BTW - OpenSSL achieved outstanding cycle/per-byte numbers for AES-OCB on AESNI architectures with patch due to Polyakov late last year: https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33ceaa5623b
> 
> Aaron



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.cert.at/pipermail/ach/attachments/20160621/3e9a5af3/attachment.sig>