Re: my revised proposal for ECB (was: Support for ECB - proposal for a decision)

Hi.
for ECB issues,
I think we have to give as much as choices to developers.

in some case I feel the security concerns became one of biggest huddle in
webcrypto discussions.

I agree Zooko's opinion.
we have to give more freedom, then we can expect more creative result.

regards
mountie

On Mon, Oct 8, 2012 at 12:32 PM, Zooko Wilcox-OHearn <
zooko@leastauthority.com> wrote:

> Dear Ryan:
>
> I'm actually quite sympathetic to your argument that the security of
> an app is ultimately determined more by the authors of that app than
> by the authors of the crypto library's API. That is the sort of
> argument that is very plausible to me, and I'm sure that it is often
> correct.
>
> However, we also have empirical evidence to the contrary: that
> sometimes the design of the crypto API can determine the security of
> the apps that use it. There are plenty of historical examples of apps
> using ECB mode for encrypting plaintexts and thus failing to provide
> confidentiality, but of course the meaning of such examples is open to
> interpretation. You can always wonder if the security failure wasn't
> due to writers of the app rather than to the crypto library that they
> used. Maybe the same app writers would have made a different fatal
> mistake if the library hadn't offered them ECB mode.
>
> That's why this recent example of the "Beaker" middleware is so
> informative: it is a case where the same people (the maintainers of
> Beaker), addressing exactly the same use case, implemented it twice
> using two different crypto APIs. One implementation was flawed due to
> its use of ECB mode, and users that rely on it are vulnerable to
> having their sessions hijacked by an attacker. The other
> implementation — using the crypto library that I designed — has no
> such vulnerability.
>
> This should be taken as evidence that crypto API design can affect the
> safety of actual people.
>
> This is something that I value.
>
> Now, this doesn't mean that all other values pale in comparison and we
> have to spend the rest of our lives debating how many security angels
> can dance on the head of a pin. Engineering is about trade-offs, and
> I'm willing to support trade-offs that sacrifice some of my values in
> order to gain more of others. I agreed, in last week's conference
> call, to support the inclusion of ECB because it can be used to
> implement certain other algorithms efficiently, and among efficient
> ways to do that, it is the easiest for everyone to understand.
> Efficiency and ease of understanding are things I value, too.
>
> So, if you're willing to go along with this, then let's talk about how
> to spell out the standard in a way that is easy for us to finish
> writing and for others to read, and also, if possible, avoids leading
> our readers into traps. My current proposal is to avoid classifying
> ECB as an "encryption mode" like CBC or CTR, since that is what
> previous APIs have often done, and it has often led people into
> thinking that ECB can be used to encrypt their data, which it can't
> safely do. (* Except in the case that their data is <= 16 bytes in
> length.)
>
> In addition to the possible benefit of avoiding such security
> failures, this kind of documentation may also aid readability, which
> you've said is a value to you.
>
> How about this?
>
>  • Public key encryption: RSA-OAEP, RSAES-PKCS1-v1_5
>  • Public key digital signature: ECDSA, RSA-PSS, RSASSA-PKCS1-v1_5
>  • Key agreement: ECDH, Diffie-Hellman
>  • Authenticated encryption: AES-OCB, AES-GCM
>  • Unauthenticated encryption: AES-CTR, AES-CBC
>  • Message authentication code: HMAC-SHA256
>  • Key-derivation functions: HKDF, PBKDF2
>  • Hash functions: SHA-2-256, SHA-3-256
>  • Primitives: AES-ECB
>
> I also still want us to agree on a clearly worded warning message in
> the documentation of ECB. The text I suggested earlier still sounds
> good to me:
>
> "NOTE: This function does not, except in special cases, conceal the
> content of the message and cannot, except in special cases, be used
> for encryption. It is included only for the use of cryptographers to
> implement other cryptographic algorithms. For an encryption function,
> please see the functions listed under Authenticated Encryption or
> Unauthenticated Encryption."
>
> This is more accurate than, for example, the warning about ECB in the
> OWASP glossary ¹:
>
> "This mode should not be used under any circumstances."
>
> ☺
>
> As to the issues about padding, I think what you wrote is right. ECB's
> issues with padding are the same as CBC's and no doubt we'll want
> their APIs to handle padding in the same way.
>
> ¹ http://owasp.com/index.php/Glossary#Electronic_Code_Book_mode
>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.com
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World