Re: Support for ECB

On Mon, Sep 10, 2012 at 11:39 AM, Zooko Wilcox-OHearn
<zooko@leastauthority.com> wrote:
> I don't want to encourage people who know no better to pick ECB mode
> from a list of modes.
>
> But I do want to have access to a naked AES function for uses that
> aren't satisfied by any modes.

Agreed

>
> Why not include a naked AES function, but don't list it among the
> optional modes and don't call it "ECB mode"? Call it "bare_AES" and
> specify it to raise an exception unless the data input is exactly one
> block long.

While I understand the desire to make it "harder to use == harder to
get wrong", I'm concerned that the latter requirement would be a real
loss for possible performance. The "ideal" situation is to throw all
of your data at processData(), and then let the onProgress/onComplete
spit back the result. That minimizes any crossing of security
boundaries, ACL checks, process/context/thread switches, etc.
Requiring block-size updates really just rules out all of those.

I think it depends on our naming (ISSUE-37) and how modes are handled
(ISSUE-29), but as we discussed early on, I'd support the concept of
an "unsafe" namespace or naming to indicate that this shouldn't be
used for "new" apps. Implementations that are doing "safe" things
(like implementing CCM atop ECB) would know that *their* use is safe,
whereas unskilled-in-the-cryptographic-dark-arts developers should
hopefully be suitably discouraged.

>
> Regards,
>
> Zooko
>

Received on Monday, 10 September 2012 18:50:45 UTC