Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10 March 2013 01:25, Tony Arcieri tony.arci...@gmail.com wrote: On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. for example they recommend CBC mode which is fraught with problems. Where? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10 Mar 2013, at 10:51, Ben Laurie wrote: On 10 March 2013 01:25, Tony Arcieri tony.arci...@gmail.commailto:tony.arci...@gmail.com wrote: On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.commailto:noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. for example they recommend CBC mode which is fraught with problems. Where? Right here: http://www.w3.org/TR/WebCryptoAPI: 19.1. Recommended algorithms This section is non-normative As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations. However, in order to promote interoperability for developers, there are a number of recommended algorithms. The recommended algorithms are: * HMAChttp://www.w3.org/TR/WebCryptoAPI/#hmac using SHA-256http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256 * RSASSA-PKCS1-v1_5http://www.w3.org/TR/WebCryptoAPI/#rsassa-pkcs1 using SHA-256http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256 * ECDSAhttp://www.w3.org/TR/WebCryptoAPI/#ecdsa using P-256http://www.w3.org/TR/WebCryptoAPI/#dfn-NamedCurve-p256 curve and SHA-256http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256 * AES-CBChttp://www.w3.org/TR/WebCryptoAPI/#aes-cbc ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10 March 2013 01:57, Ryan Sleevi ryan+cryptogra...@sleevi.com wrote: Finally, the recommendations are for what implementations should support. There is not any mandatory to implement suite at this point. Instead, it's looking at what are the algorithms in vast, sweeping use today in a number of protocols and applications, and that developers will expect or need supported to implement a variety of applications *that already exist today*. Whilst I agree with most of what you said, if you want to have interop with existing apps, then RSA OAEP is an odd choice, and the lack of RC4 is also notable. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10 March 2013 10:58, Paterson, Kenny kenny.pater...@rhul.ac.uk wrote: On 10 Mar 2013, at 10:51, Ben Laurie wrote: On 10 March 2013 01:25, Tony Arcieri tony.arci...@gmail.com wrote: On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. for example they recommend CBC mode which is fraught with problems. Where? Right here: http://www.w3.org/TR/WebCryptoAPI: Somehow missed that. Thanks. 19.1. Recommended algorithms This section is non-normative As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations. So ... despite Ryan's claim that the recommendations are for API implementers, it says here that they're also for users of the API. In which case, clearly, AE modes should be recommended. However, in order to promote interoperability for developers, there are a number of recommended algorithms. The recommended algorithms are: HMAC using SHA-256 RSASSA-PKCS1-v1_5 using SHA-256 ECDSA using P-256 curve and SHA-256 AES-CBC ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10 Mar 2013, at 11:01, Ben Laurie wrote: On 10 March 2013 10:58, Paterson, Kenny kenny.pater...@rhul.ac.uk wrote: Right here: http://www.w3.org/TR/WebCryptoAPI: Somehow missed that. Thanks. 19.1. Recommended algorithms This section is non-normative As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations. So ... despite Ryan's claim that the recommendations are for API implementers, it says here that they're also for users of the API. In which case, clearly, AE modes should be recommended. I fully agree. We have already made this point to the WebCrypto folks (see: lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html), but without managing to bring about a shift in their position. If people want to see how badly things can go wrong when you mix legacy (i.e. insecure) and secure algorithms, see, for example this NDSS 2013 paper: http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ [Full disclosure: I am an author on the paper.] Cheers Kenny ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
Ryan Sleevi writes: What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? Here's the abstract of The security impact of a new cryptographic library (http://cr.yp.to/highspeed/coolnacl-20120725.pdf): This paper introduces a new cryptographic library, NaCl, and explains how the design and implementation of the library avoid various types of cryptographic disasters suffered by previous cryptographic libraries such as OpenSSL. Specifically, this paper analyzes the security impact of the following NaCl features: no data flow from secrets to load addresses; no data flow from secrets to branch conditions; no padding oracles; centralizing randomness; avoiding unnecessary randomness; extremely high speed; and cryptographic primitives chosen conservatively in light of the cryptanalytic literature. The paper cites and analyzes cryptographic failures in SSH, ECDSA in SSL, RSA in SSL, Linux disk encryption, the PlayStation 3, et al. What's particularly convincing is to look at _newer_ failures, such as the very recent Lucky 13 attack recovering plaintext from SSL, and observe that those failures would have been prevented by precisely the NaCl features identified in this document. (Lucky 13 relies on padding oracles and on these prohibited forms of data flow.) These NaCl features are at a quite different level from the features advertised by cryptographic APIs from the dark ages (e.g., we support MD5 and RSA-512), and in many cases are in direct conflict with those features. This is one of the reasons that NaCl has a simple high-level API. Of course, simplicity has other benefits. As for specification, there's a state-of-the-art Cryptography in NaCl document (http://cr.yp.to/highspeed/naclcrypto-20090310.pdf) that has complete self-contained definitions of every aspect of key generation, encryption, and authentication involved in NaCl's crypto_box(); plus an end-to-end example expressed both as * self-contained Python/Sage test scripts that compute every detail of the crypto and * simple test programs using NaCl, of course producing the same results; plus security notes. Someone who wants to write a new implementation that interoperates with crypto_box() doesn't need to read anything else. I'm not saying that this is the end of the story---implementors should also learn about crypto_sign(), constant-time code, and more---but it's way ahead of the documentation mess that one has to read to reimplement other existing protocols with similar functionality. And how can we be sure that the problems that NaCl sets out to solve are the same problems developers want or need to solve, especially when all the evidence suggests otherwise? The main reason for a developer to use a cryptographic library is to protect data against espionage, sabotage, etc. There's ample evidence that most cryptographic libraries _don't_ actually manage to protect data---and imitating their decisions is simply going to produce more security disasters. Of course, this doesn't imply that NaCl is what developers want, but high-profile applications such as DNSCrypt are in fact using NaCl in ways that seem easily generalizable to other applications. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
Everyone's got some negatives to say, drawing from their huge experience of how they do things, and things they've read from books, and things that powerful communities have proselytised over the short ages of public domain crypto. Unfortunately, we're not at the point, as a community, of saying much that is positive, in the sense that the right way allows a newcomer to the field to pick up the right tools and get to the end of the road with the cryptoplumbing locked in and reasonably secure, in efficient time cost. As we can show why most advice is nonsense fairly easily, I tend to say that the best thing to do is to plough on regardless -- do what you can, and do the best you can. And in the process we -- both you and the wider community -- will learn. This works because, while the insider generally underestimates the complexity of the security field by orders of magnitude, the wider security community generally underestimates the complexity of the business by similar orders of magnitude. An insider can deploy tricks and intuition that outsiders cannot, and can know more quickly when some ivory tower edifice is tilting or falling, in ways that outsiders will not see, because latter don't walk around the building, they only stand in front of its best face. To get off the pot and say what I think: I personally do not thing an API will help a lot. (Especially if there is a committee involved.) But, I think if you had a reference implementation for that API, then it would have a chance. The developer view here is that only code serves as code, before any API. Sure, an API provides an easy way to understand the code. Sometimes it allows substitution (but that's more a hope than a reality). It can provide choice and it can frame the way to do good crypto. But in reality, it's still dominated by the need for code. iang On 10/03/13 04:57 AM, Ryan Sleevi wrote: On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote: On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. I have a blog post about it forthcoming, but I'd like to share the tl;dr version here: The normative parts of the specification seem mostly fine. The specification provides no normative advice about what algorithms to use, and worse, provides a non-normative listing of algorithms which are not authenticated encryption modes (for symmetric ciphers, the only mode listed in the spec is AES-GCM) That is correct. This is not a How to use cryptography spec. This is an API. This is not an evangelical API. I realize the crypto clergymen may not like this, but APIs that proselytize do not somehow educate more. They merely get in the way of people who know what they're doing, and the people who don't know what they're doing will find plenty of other ways to screw up (eg: XSS, XSRF, insecure cookies, clickjacking, framing, etc). Plus, it only takes one Stack Overflow question answer, or one bad W3CSchools post (redundant much?), to undermine whatever message was intended for those crypto black sheep. At the very least, I'd like to see the non-normative examples section expanded to include a lot more authenticated encryption modes (EAX mode comes to mind, and seeing support for NaCl algorithms like crypto_box and crypto_secretbox would be super). Right now they give some rather poor recommendations, for example they recommend CBC mode which is fraught with problems. What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? If you don't trust developers to be able to use the API correctly, what makes you think that they can sufficiently understand the security guarantees that NaCl does - and *doesn't* - provide. And how can we be sure that the problems that NaCl sets out to solve are the same problems developers want or need to solve, especially when all the evidence suggests otherwise? Arguably, the answer for whatever use case you imagine NaCl meeting can almost certainly be met through JOSE, if and when it ever gets its act together. If you want something high level, use something designed to be interoperable (and hopefully, JOSE will actually use JSON by then). As much respect as I have for DJB, Sodium's existence is proof positive of what NaCl does and doesn't set out to do. Finally, the recommendations are for what implementations should support. There is not any mandatory to implement suite at this point. Instead, it's looking at what are the algorithms in vast, sweeping use today in a number of protocols and applications, and that developers will expect or need supported to implement a variety of applications *that already exist today*. Finally, it'd be great to see someone like NIST or ECRYPT provide browser
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein d...@cr.yp.to wrote: Ryan Sleevi writes: What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? Of course, this doesn't imply that NaCl is what developers want, but high-profile applications such as DNSCrypt are in fact using NaCl in ways that seem easily generalizable to other applications. There are linux distributions that do not consider or cite NaCl. If an Open Source developer did not follow other sources of discussion he not would know it. I dunno why. Perhaps it is due to the FIFS 140. I am sorry if the observation is OT. http://fedoraproject.org/wiki/FedoraCryptoConsolidation ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On 10/03/13 20:25 PM, yersinia wrote: On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein d...@cr.yp.to mailto:d...@cr.yp.to wrote: Ryan Sleevi writes: What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? Of course, this doesn't imply that NaCl is what developers want, but high-profile applications such as DNSCrypt are in fact using NaCl in ways that seem easily generalizable to other applications. There are linux distributions that do not consider or cite NaCl. If an Open Source developer did not follow other sources of discussion he not would know it. I dunno why. Perhaps it is due to the FIFS 140. I am sorry if the observation is OT. One would hope that someone would put a little more thought into crypto than it's available in Linux http://fedoraproject.org/wiki/FedoraCryptoConsolidation Oh my, 11 popular crypto libraries. Wait, I've got an idea... http://xkcd.com/927/ iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On Sun, Mar 10, 2013 at 6:58 PM, ianG i...@iang.org wrote: On 10/03/13 20:25 PM, yersinia wrote: On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein d...@cr.yp.to mailto:d...@cr.yp.to wrote: Ryan Sleevi writes: What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? Of course, this doesn't imply that NaCl is what developers want, but high-profile applications such as DNSCrypt are in fact using NaCl in ways that seem easily generalizable to other applications. There are linux distributions that do not consider or cite NaCl. If an Open Source developer did not follow other sources of discussion he not would know it. I dunno why. Perhaps it is due to the FIFS 140. I am sorry if the observation is OT. One would hope that someone would put a little more thought into crypto than it's available in Linux You are certainly right. Many operating systems are perhaps too much conservative in their security systems, encryption is no exception. But the spread of good libraries like Naci, in commercial or open source product, requires more effort from everyone. It is not so simple. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. I have a blog post about it forthcoming, but I'd like to share the tl;dr version here: The normative parts of the specification seem mostly fine. The specification provides no normative advice about what algorithms to use, and worse, provides a non-normative listing of algorithms which are not authenticated encryption modes (for symmetric ciphers, the only mode listed in the spec is AES-GCM) At the very least, I'd like to see the non-normative examples section expanded to include a lot more authenticated encryption modes (EAX mode comes to mind, and seeing support for NaCl algorithms like crypto_box and crypto_secretbox would be super). Right now they give some rather poor recommendations, for example they recommend CBC mode which is fraught with problems. Finally, it'd be great to see someone like NIST or ECRYPT provide browser vendors with normative advice on algorithms to standardize on. The existing WebCrypto spec leaves browser vendors to their own devices, and in that eventuality, the browser venders will probably wind up implementing the W3C spec's (poorly chosen) non-normative recommendations. For an in-depth look at the problems, I'd recommend checking out Matt Green's blog post: http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote: On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com wrote: The Web Cryptography Working Group looks well organized, provides a very good roadmap, and offers good documentation. http://www.w3.org/2012/webcrypto/. I have a blog post about it forthcoming, but I'd like to share the tl;dr version here: The normative parts of the specification seem mostly fine. The specification provides no normative advice about what algorithms to use, and worse, provides a non-normative listing of algorithms which are not authenticated encryption modes (for symmetric ciphers, the only mode listed in the spec is AES-GCM) That is correct. This is not a How to use cryptography spec. This is an API. This is not an evangelical API. I realize the crypto clergymen may not like this, but APIs that proselytize do not somehow educate more. They merely get in the way of people who know what they're doing, and the people who don't know what they're doing will find plenty of other ways to screw up (eg: XSS, XSRF, insecure cookies, clickjacking, framing, etc). Plus, it only takes one Stack Overflow question answer, or one bad W3CSchools post (redundant much?), to undermine whatever message was intended for those crypto black sheep. At the very least, I'd like to see the non-normative examples section expanded to include a lot more authenticated encryption modes (EAX mode comes to mind, and seeing support for NaCl algorithms like crypto_box and crypto_secretbox would be super). Right now they give some rather poor recommendations, for example they recommend CBC mode which is fraught with problems. What use case makes the NaCl algorithms (whose specification is merely 'use NaCl', which boils down to Use Salsa+Curve25519) worthwhile? If you don't trust developers to be able to use the API correctly, what makes you think that they can sufficiently understand the security guarantees that NaCl does - and *doesn't* - provide. And how can we be sure that the problems that NaCl sets out to solve are the same problems developers want or need to solve, especially when all the evidence suggests otherwise? Arguably, the answer for whatever use case you imagine NaCl meeting can almost certainly be met through JOSE, if and when it ever gets its act together. If you want something high level, use something designed to be interoperable (and hopefully, JOSE will actually use JSON by then). As much respect as I have for DJB, Sodium's existence is proof positive of what NaCl does and doesn't set out to do. Finally, the recommendations are for what implementations should support. There is not any mandatory to implement suite at this point. Instead, it's looking at what are the algorithms in vast, sweeping use today in a number of protocols and applications, and that developers will expect or need supported to implement a variety of applications *that already exist today*. Finally, it'd be great to see someone like NIST or ECRYPT provide browser vendors with normative advice on algorithms to standardize on. The existing WebCrypto spec leaves browser vendors to their own devices, and in that eventuality, the browser venders will probably wind up implementing the W3C spec's (poorly chosen) non-normative recommendations. NIST or ECRYPT? Why not KISA or GOST? After all, everyone loves SEED and GOST 28147-89... The answer is that the choice of algorithms were motivated by two factors: 1) As stated in the charter, exposing (some of) the cryptographic services already inherent in browser applications today. [In order to provide constant time, correct, validated implementations of the algorithms - things impossible in JS today] 2) The choice of algorithms that are meaningful to web application developers - which includes the W3C SysApps WG - which has an *entirely* different security model than the drive by web. Support for legacy algorithms in order to support those esoteric protocols like SSH, PGP, or S/MIME (or would you rather your browser bake them in? *shudder*), as well as the choice of algorithms that are suitable for future work (and, notably, being explored in JOSE) For an in-depth look at the problems, I'd recommend checking out Matt Green's blog post: http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html Matt's post, besides being entertaining and certainly with some meritorious points, basically sums up as No backwards compatibility, and only give people what the priesthood accept. Respectfully, that doesn't lead to more secure code, nor does it lead to what smart people - people who know what they're doing - *actually* want or need (as done through repeated surveys from participants and non-participants of the WG). While I can understand that, on a list such as this, people are well trained to turn their noses upwards at bad cryptography, this is not going to usher in some Apocalypse that
