Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stanford Javascript Crypto Library

crypto.stanford.edu

Post reply on HN
Print view View original

31–40 of 91 posts

Re: Stanford Javascript Crypto Library

#31

Post by tlrobinson »

untothebreach wrote: post #29
tlrobinson wrote: post #24

Earlier quoted context omitted.

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

HTTPS just tells you that you are talking to the 'right' server. It doesn't tell you anything about the validity of the javascript that the server is sending you.

In both cases you're using a private key, which you need to protect, to authenticate you are who you say you are. I suppose the difference is a JS bundle could be signed offline and uploaded to a potentially insecure server/CDN/app store/whatever.

Re: Stanford Javascript Crypto Library

#32

Post by jonknee »

jonpaul wrote: post #27
tlrobinson wrote: post #24

Earlier quoted context omitted.

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.

If the server is compromised you're SOL.

Re: Stanford Javascript Crypto Library

#33

Post by jonknee »

Everlag wrote: post #9
meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

Perhaps the key to crypto in the browser would be to implement it in extensions rather than on webpages? Extensions run in a higher level of security clearance, are sandboxed from the rest of the page, and are much more intolerant of code injection.

Built into the browser would be even better (like SSL).

Re: Stanford Javascript Crypto Library

#34

Post by nsmartt »

lisper wrote: post #3
nsmartt wrote: post #2

This could lead to a rise in services offering client-side encryption. A 'better' homepage might help.

Anyone who needs a "better" home page probably ought not to be using it.

Developers with a budding interest in cryptography should certainly be using this, even if they shouldn't be asking users to trust their work. Your mentality excludes a rather large set of users who may not realize what they've found.

Also, a homepage with a pitch, a visually appealing design, etc would likely generate some buzz from people who aren't interested in using it but are interested in the concept. This could very well lead to discovery by developers who would otherwise have never found it.

Re: Stanford Javascript Crypto Library

#35

Post by bradleyland »

tlrobinson wrote: post #31
untothebreach wrote: post #29

Earlier quoted context omitted.

HTTPS just tells you that you are talking to the 'right' server. It doesn't tell you anything about the validity of the javascript that the server is sending you.

In both cases you're using a private key, which you need to protect, to authenticate you are who you say you are. I suppose the difference is a JS bundle could be signed offline and uploaded to a potentially insecure server/CDN/app store/whatever.

The fact that a private key is used doesn't mean HTTPS and code signing are the same.

HTTPS says, "The communications you send to the server cannot be intercepted and changed between the client and server, and the identity of the server you're connecting to has been verified by one of your trusted certificate authorities."

HTTPS promises that your communications cannot be snooped on, and the person you're talking to is verified by a mutually agreed upon third-party.

Code signing does something entirely different. Code signing says, "The code you're about to run was written by the developer specified in the signing certificate, and has not been modified since it was signed. The identity of the developer has been verified by one of your trusted certificate authorities."

So the practical difference is this:

Say your browser requests https://domain.com/random.js. HTTP ensures that you're connecting to domain.com, and that your communications won't be changed or observed in transit. However, it does not guarantee that some malicious third-party didn't overwrite random.js on the server. With code signing, you can accomplish that. An author can "sign" a code package so that any alterations to the code itself would cause a certificate invalidation.

Re: Stanford Javascript Crypto Library

#36

Post by jonpaul »

jonknee wrote: post #32
jonpaul wrote: post #27

Earlier quoted context omitted.

Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.

If the server is compromised you're SOL.

Exactly. That's why I'm advocating for a signed JavaScript/HTML/webapp standard of some sort.

Re: Stanford Javascript Crypto Library

#37

Post by bradleyland »

jonknee wrote: post #32
jonpaul wrote: post #27

Earlier quoted context omitted.

Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.

If the server is compromised you're SOL.

That is not true if you're using code signing. If someone compromises the server, they can overwrite the files, but they cannot forge code signing without additional access to code signing private keys.

Security is achieved through layers. No single layer can protect you from everything, but we lay down the gauntlet in the hopes that an attacker will encounter a road block that they cannot pass.

Re: Stanford Javascript Crypto Library

#38

Post by jorgeleo »

malandrew wrote: post #23
meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

What if the sites used SJCL by default, but urged the user to install an official browser plugin that detects the presence of SJCL on a page and falls back to the browser's own copy of SJCL, always trusting it over any copy sent over the wire. It's not perfect but at least gives users a stepping stone to secure communications. The biggest problem with getting users to adopt crypto is giving them stepping stones to so…

Steve Jobs is turning in his thumb... you just suggested the p word

Re: Stanford Javascript Crypto Library

#39

Post by pdubs »

meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

It's useful if you store things in local storage.

Re: Stanford Javascript Crypto Library

#40

Post by methehack »

goldfeld wrote: post #12

Relatedly, I'm looking for Javascript checksum implementations, especially sum24 or any other good 24bit hashing algorithm, and I couldn't find anything. Does anyone know of canonical hashing implementations for CRC and checksum (not crypto-level, I need short, short hashes) for JS?

I was thinking about this too -- but if they compromised your encryption JS couldn't they also compromise your checksum JS?
Post reply on HN