Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[yersinia]

On Sun, Mar 10, 2013 at 6:58 PM, ianG  wrote:

> On 10/03/13 20:25 PM, yersinia wrote:
>
>> On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein > > 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)

[ianG]

On 10/03/13 20:25 PM, yersinia wrote:

On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein 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)

[yersinia]

On Sun, Mar 10, 2013 at 12:20 PM, D. J. Bernstein  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)

[ianG]

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  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
  vendor

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[D. J. Bernstein]

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)

[Paterson, Kenny]

On 10 Mar 2013, at 11:01, Ben Laurie wrote:

> On 10 March 2013 10:58, Paterson, Kenny  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)

[Ben Laurie]

On 10 March 2013 10:58, Paterson, Kenny  wrote:
>
> On 10 Mar 2013, at 10:51, Ben Laurie wrote:
>
> On 10 March 2013 01:25, Tony Arcieri  wrote:
>
> On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  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)

[Ben Laurie]

On 10 March 2013 01:57, Ryan Sleevi  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)

[Paterson, Kenny]

On 10 Mar 2013, at 10:51, Ben Laurie wrote:

On 10 March 2013 01:25, Tony Arcieri 
mailto:tony.arci...@gmail.com>> wrote:
On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton 
mailto: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:

  *   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)

[Ben Laurie]

On 10 March 2013 01:25, Tony Arcieri  wrote:
> On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  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)

[Ryan Sleevi]

On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote:
>  On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  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 

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Tony Arcieri]

On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  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