- From: <bugzilla@jessica.w3.org>
- Date: Sat, 12 Jul 2014 16:44:31 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607 infinity0@pwned.gg changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |infinity0@pwned.gg --- Comment #29 from infinity0@pwned.gg --- Hi, I spoke with Harry briefly recently, and he told me an overview of this bug. Having seen how non-experts try to use cryptography libraries, I support the move to eventually deprecate non-authenticated modes of encryption. I have a few concrete suggestions that don't seem to have been considered elsewhere yet: A. Force modes like {CTR,CBC,CFB} to be paired with a MAC, by requiring the Algorithm object to include a subfield that specifies a mac Algorithm object. B. Put those modes in yet another module, like window.crypto.subtle.old I don't think it is so important to avoid "creat[ing] a point in time snapshot of a security state". This can be applied to *any* security spec that you might care to write about. Every spec has an implicit time-context, you have to expect future security implementors to understand this. The alternative is to not commit to any advice about anything, instead giving vague recommendations to "RTF existing literature", which very few application authors will do. "Any advice against is, implicitly, advice for" - a distinction should still be made between "maybe-bad" and "definitely-bad". I do think it's a good idea to have separate documentation for implementors vs authors. No-one is in both roles, and putting both in the same document makes it more likely important advice will cause TL;DR. For example, things like "non-constant-time ECC curve implementations" is an implementation concern, whereas the abuse of {CTR,CBC,CFB} mode would be a concern for application authors. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Saturday, 12 July 2014 16:44:33 UTC