Re: [hybi] It's time to ship

[Bjoern Hoehrmann <[e-mail]>]

* Adam Barth wrote:
>Here's an example RFC that uses AES-128-CTR
>
>http://www.ietf.org/rfc/rfc4344.txt
>
>I believe it's technically defined by combining
>http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf and
>http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, the
>later of which contains test vectors.  (Careful readers will notice
>that my example is wrong.)

I agree your example is wrong. So the concern was a chosen ciphertext
attack. For simplicity let's say Websocket frames are just 16 byte long
blocks and the attacker has full control over them. From the same 16
byte input the browser would generate at most 2^32 ciphertexts, so an
attacker can compute the masked frame for one of the nonces and send it
over and over again, eventually his ciphertext will appear.

Example: The handshake establishes the per-connection key K, I want to
put "0123456789ABCDEF" on the wire, I compute "0123456789ABCDEF" `xor`
AES(K, 0x12345678000000...) and ask the browser to send that again and
again; eventually it will pick 0x12345678 as per-frame nonce, it will
xor with the same AES value, and I get my attack payload on the wire
(if the block counter is not reset, I'd just take that into account by
recomputing the masked frame still assuming the same per-frame nonce.)

So is there an error in this analysis, or is the argument simply that
using your AES scheme seems to make attacks a little bit harder?
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/