Hacker News new | past | comments | ask | show | jobs | submit login

Unfortunately, the Web Crypto API doesn't automatically get you safe cryptography either. It was added by the W3C to allow video vendors to implement content DRM in pure Javascript rather than requiring plugins, and so it includes a great deal of legacy crypto.

Long story short, you need an expert in cryptography to design this for you, whether or not you use WebCrypto.

This isn't something you should take risks with. It would be better to advertise a decentralized social network with NO CRYPTOGRAPHY (which is what this essentially is) than to say it has "cryptography that hasn't been audited" (which most users won't distinguish from real crypography).




1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "

2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.

3. Here is a short description of the basic concept: Client and server are seperated. The client software is basically what is hosted on Github. Its source code must be protected from MITM attacks of course, so it is best to ship it as standalone, downloadable application in the final release. THE CLIENT CODE WILL NOT BE OFFERED BY A SERVER IN A PRODUCTION VERSION.

So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.

Next, you have a key directory. It is signed after every modification with a secret salt which was generated by the client (and not known by the server) at signup. The keydirectory contains all the verified public keys of the user. (Protecting it from replay attacks would be worth another essay here) Now when you write messages for example, you get the public key from this directory and encrypt/sign it basically like in PGP. So the focus of this preview is not on the crypto primitives, but rather on the concept itself.

Edit: I hope this does not sound too unfriendly, I am very happy about your feedback and I promise I will look for further advice regarding the crypto/protocol ;)


> 1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "

So they say. You'd be hard-pressed to find a cryptographer that likes Web Crypto.

> 2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.

Shameless plug: https://paragonie.com/service/code-review

> So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.

Are you going to build it in, say, Electron? That's pretty neat.

What padding mode are you going to use for RSA? What hash function for MGF1?

Are you going to also employ digital signatures? Will you use the same RSA keypair for signatures?

What about your other parameters? (There are attacks for e=3 RSA signatures, for example.)

What cipher mode are you going to use for AES? What key size? Are you going to MAC then Encrypt, Encrypt and MAC, or Encrypt then MAC? I'm assuming the third option.

How are keys going to be authenticated to the clients? How will they detect/prevent the server from substituting a user's RSA (eww) key for one of their own choosing?

How are you going to derive your encryption keys from the password?

Why not save a lot of time and frustration and just use node-sodium (assuming Electron of course)?

    - Transport: crypto_sign() + crypto_sign_open()
    - Encryption: crypto_box() + crypto_box_open()
    - Key derivation: crypto_pwhash() + crypto_box_seed_keypair()
      + crypto_sign_seed_keypair()
    - Salts, keys, nonces, etc: randombytes_buf()
Life is easier with sodium. https://paragonie.com/blog/2015/09/how-to-safely-implement-c...


Even if he makes all those decisions correctly the system won't support forward secrecy.


Why do you think I separated crypto_sign() from crypto_box() in my description?


It seems like there would be a lot of uses for something like a jQuery for the WebCrypto API. There are enough ways to get it wrong, and enough commonality among 80% use cases, I can see something like this being better than the alternative.


WebCrypto is a potluck of popular cryptography standards, chosen by committee.

What you want instead is a library that carefully selects primitives with an emphasis on:

    1. Security
    2. Performance
    3. Ease of use
You want a high-level API, like I'm building for PHP 7.1, not a low-level API, like openssl, mcrypt, WebCrypto, etc.


Google's NaCL (i.e. NativeClient, not Libsodium-- awful overlap in terminology there) + Crypto_box + PPAPI seems to be really easy to implement as well as really secure, but Mozilla wants nothing to do with NaCL (again, the Google Native Client for Chrome/Chromium - not the DJB lib).

Edit: and that's what I get for skipping over half the posts in this thread. You specifically mentioned crypto_box/libsodium. No surprise there, you seem pretty well-informed from the 50% of the posts I did read in this thread ;). Zimmerman got it right amazingly right with PGP 20 years ago. The men and women at keybase.io are doing a great job trying to bridge the gap in the interim. Your route is the route I'm taking right now as I'm building out but with USB key and/or cell phone authenticators. Speaking of which, Thomas, in a few weeks if you have some spare time I'd love for you to look at what hopefully isn't a travesty of a product. (I minimized as much as I could re-using existing components with the intention of limiting the potential of bugs I could introduce, but Johnny's gonna have crypto soon if I have my way.)


> No surprise there, you seem pretty well-informed from the 50% of the posts I did read in this thread ;)

Heh, thank you. :)

> Speaking of which, Thomas, in a few weeks if you have some spare time I'd love for you to look at what hopefully isn't a travesty of a product.

If he doesn't, feel free to ping me. ;)


Yes just something that implements signatures and private messages in the best way web crypto allows for. Bonus points for encapsulating the best practices rather than just documenting the footguns.


2016 and using crypto as a lib is still so ludicrously difficult you still get advice to "get a crypto expert".

The failure of current crypto experts to create a usable crypto story is 100% why we can't have nice things.


That's exactly what I think as well. It shouldn't be that difficult to get basic crypto to an application.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: