how is it different from diaspora?
Show HN: A decentralized social network with end-to-end encryption
11–20 of 62 posts
Re: Show HN: A decentralized social network with end-to-end encryption
#12The cryptography in this system does not appear to be safe. Apart from the fact that it's browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't), it's also using outdated RSA crypto constructions that are vulnerable to attacks. I think you should find an expert to work on this project with you and provide the cryptographic design for yo…
Yes, as written on top this is a technology preview, so it is not safe yet.
Furthermore the production version will use the web crypto api.
The client software must be shipped packaged as a standalone application (Apache Cordova etc.) with integrity protection or hosted on your own server and served via https. Yeah, the goal is actually to get some feedback about the crypto design and improve it :)
Re: Show HN: A decentralized social network with end-to-end encryption
#13how is it different from diaspora?
It has end-to-end encrpytion - so if you are hosted on a friend's server for example, the friend can not read your messages, which might be useful :)
Re: Show HN: A decentralized social network with end-to-end encryption
#14The cryptography in this system does not appear to be safe. Apart from the fact that it's browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't), it's also using outdated RSA crypto constructions that are vulnerable to attacks. I think you should find an expert to work on this project with you and provide the cryptographic design for yo…
Yes, as written on top this is a technology preview, so it is not safe yet. Furthermore the production version will use the web crypto api. The client software must be shipped packaged as a standalone application (Apache Cordova etc.) with integrity protection or hosted on your own server and served via https. Yeah, the goal is actually to get some feedback about the crypto design and improve it :)
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).
Re: Show HN: A decentralized social network with end-to-end encryption
#15I support the idea behind this, but I love the community on Diaspora, and more importantly it is also decentralized and open-source.
Re: Show HN: A decentralized social network with end-to-end encryption
#16The cryptography in this system does not appear to be safe. Apart from the fact that it's browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't), it's also using outdated RSA crypto constructions that are vulnerable to attacks. I think you should find an expert to work on this project with you and provide the cryptographic design for yo…
Isn't this the one application were JS crypto is OK? As far as I understand, that is not at all, here JS crypto is used to offload the computation from a trusted server to a trusted client and afterwards the server distributes the encrypted message further.
Re: Show HN: A decentralized social network with end-to-end encryption
#17Earlier quoted context omitted.
Yes, as written on top this is a technology preview, so it is not safe yet. Furthermore the production version will use the web crypto api. The client software must be shipped packaged as a standalone application (Apache Cordova etc.) with integrity protection or hosted on your own server and served via https. Yeah, the goal is actually to get some feedback about the crypto design and improve it :)
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…
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 ;)
Re: Show HN: A decentralized social network with end-to-end encryption
#18The cryptography in this system does not appear to be safe. Apart from the fact that it's browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't), it's also using outdated RSA crypto constructions that are vulnerable to attacks. I think you should find an expert to work on this project with you and provide the cryptographic design for yo…
Isn't this the one application were JS crypto is OK? As far as I understand, that is not at all, here JS crypto is used to offload the computation from a trusted server to a trusted client and afterwards the server distributes the encrypted message further.
Yes, exactly :)
Re: Show HN: A decentralized social network with end-to-end encryption
#19Earlier quoted context omitted.
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…
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…
> 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()
Re: Show HN: A decentralized social network with end-to-end encryption
#20Earlier quoted context omitted.
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…
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…
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.