Re: Support for ECB - proposal for a decision

On 26 September 2012 07:25, Zooko Wilcox-OHearn
<zooko@leastauthority.com> wrote:
> Hi Tom, thanks for the reply.
>
> On Tue, Sep 25, 2012 at 8:58 PM, Tom Ritter <tom@ritter.vg> wrote:
>>
>> without ECB mode, I don't believe it would be possible to implement OpenPGP's CFB variant: http://tools.ietf.org/html/rfc4880#section-13.9
>
> I don't follow. Wouldn't you use a simple AES function to implement
> PGP CFB? It isn't amenable to parallel processing since the N+1'th
> block depends on the output of the N'th block's encryption. (Is that
> right? I don't understand that mode very well.)
>
> Just to be clear, I consider these two things to be very different:
> ...
> I regard the former, which I call a "bare AES function" as an
> unquestionable necessity for the WebCrypto low-level API, and the
> latter, which I call "ECB mode" as both dangerous and unnecessary. The
> fact that some people think that the difference between these two
> functions isn't worth formalizing just perplexes me, quite honestly.

Yes, you could indeed do it with bare AES.  I hadn't been following
too closely, so I may have missed if this distinction was made earlier
- but thanks for clarifying.

With bare AES you could indeed do a number of operations needed for
interop with a bunch of random protocols.  I'd like to register my
opinion that the API should expose:

 - This bare AES operation, with no concern given to the
complicated-ness of the API (as the people using it should be familiar
with crypto)
 - A 'medium-complicated' API consisting of safe operations: RSA*,
ECDSA, ECDH, HMAC, DH, SHA, PBKDF2, AES-GCM.
 - Dead-simple functions: secure_encrypt and secure_decrypt that ouput
a message as JOSE JSON.  Specification would be the following:

secure_encrypt(key, data, enc_func="AES-CTR | AES-GCM", hmac="HS256 |
HS384 | HS512")
secure_decrypt(key, structure)

 - secure_encrypt encrypts and integrity protects the data, and
outputs a JOSE structure
 - secure_decrypt takes in a JOSE structure, and decrypts the data
 - Key is either a public key or a private key (you can debate whether
it should be JOSE format or your own)
 - If it's public, it creates a random symmetric key to encrypt the data to
 - The algorithms are not required.
 - If you specify anything other than the listed algorithms, throw an exception
 - If you specify a hmac with GCM, throw an exception
 - The AES flavor is determined by the size of the key given, if it
doesn't fit one, throw an exception
 - Use JOSE to generate HMAC Keys [0]

The remaining items to debate would be:
 - In the 'medium-complicated API' should there be AES-CBC and
AES-CTR?  They're unsafe because there's no integrity protection, but
probably important enough to benefit from the native speed gain.  Big,
obvious warning labels attached.
 - Should AES-CBC be an option in the secure_encrypt function?  Again,
since integrity protection is present, it's probably okay.

I think JOSE [1] should be integrated as much as humanly possible.
JOSE and this group I think are soul mates: one specifies format
containers but not implementations, this specifies implementations but
is scared of implementing format containers.  If you don't like JOSE,
now is the time to jump in and get involved.  And it's easy, since the
IETF lets anyone send emails and get involved without maintaining
'membership status' or whatever.

-tom

[0] http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05#appendix-A.3
[1] http://datatracker.ietf.org/wg/jose/

Received on Wednesday, 26 September 2012 12:38:01 UTC