CryptAByte.com: Making cryptography (more) accessible to non-hackers(lfb.org)
lfb.org
CryptAByte.com: Making cryptography (more) accessible to non-hackers
http://lfb.org/today/cryptography-for-the-rest-of-us/
3 comments
CryptAByte author here.
The fundamental issue is whether you can trust server-side encryption. Theoretically you're right that you cannot absolutely trust my service to do what it says it does. And I would not trust it relative to client-side software either.
So, I would suggest that everyone use offline encryption, and my service exposes an API with offline encryption that works seamlessly with server-side encryption: https://cryptabyte.com/Service
Furthermore, I'm working on desktop apps which will do the encryption offline: https://cryptabyte.com/Home/Apps
But, for the average, non-technical user, the choice may be between not using encryption at all or relying on a poorly secured desktop environment and using my service. In that case, it may be more desirable to use my service than the alternative.
Regarding key strength, my hope is that most people do not enter a password, allowing the software to generate it for them. For the self-destructing emails (https://cryptabyte.com/SelfDestruct), I do not allow entering the password, but generate a secure, 32 character passphrase.
The fundamental issue is whether you can trust server-side encryption. Theoretically you're right that you cannot absolutely trust my service to do what it says it does. And I would not trust it relative to client-side software either.
So, I would suggest that everyone use offline encryption, and my service exposes an API with offline encryption that works seamlessly with server-side encryption: https://cryptabyte.com/Service
Furthermore, I'm working on desktop apps which will do the encryption offline: https://cryptabyte.com/Home/Apps
But, for the average, non-technical user, the choice may be between not using encryption at all or relying on a poorly secured desktop environment and using my service. In that case, it may be more desirable to use my service than the alternative.
Regarding key strength, my hope is that most people do not enter a password, allowing the software to generate it for them. For the self-destructing emails (https://cryptabyte.com/SelfDestruct), I do not allow entering the password, but generate a secure, 32 character passphrase.
I'm happy to have another partner- in- debunking- broken- crypto here and so a little giddy at seeing the 'tzs comment, but he missed some stuff.
Grab the source code and you'll see that --- at least as regards the cryptography components of this application --- it's practically the "Hello World" example from the MSDN System.Security.Cryptography documentation.
That's not in itself a problem; lots of "hello world"-grade libraries are useful. Unfortunately, like every other low-level crypto library, the MSDN documentation does an appalling job of showing how to write a secure cryptosystem. Blame the docs, blame Microsoft, blame the developer, but this program gets a bunch of things painfully wrong.
By way of bona fides and to start this off: I'm pretty sure that using PBKDF2 to generate the key and the IV for AES-CBC is broken; it produces a deterministic repeating IV for every message encrypted under a given key. Had the default mode for AesManaged been CTR, or had the developer chosen CTR mode, this would be a devastating problem; it would mean attackers without knowing anything about the key or even the encryption method could, in seconds, discover that CTR mode with a repeating nonce had been used and decrypt the messages. Fortunately, since the .NET default is CBC, it just subtly weakens the cryptosystem instead of killing it.
Why-oh-why derive the IV from the key? An idiom in modern cryptosystems: generate a random block and tack it to the front of the message.
Do you want to entrust your secret messages to developers who get this wrong? Only if you want to do that developer a favor. It's fine if you do, but I recommend trusting your real secrets to GPG/PGP.
There are significantly worse problems with this library (at least, I think; I read it for just a few minutes). Exercises for the interested reader.
Grab the source code and you'll see that --- at least as regards the cryptography components of this application --- it's practically the "Hello World" example from the MSDN System.Security.Cryptography documentation.
That's not in itself a problem; lots of "hello world"-grade libraries are useful. Unfortunately, like every other low-level crypto library, the MSDN documentation does an appalling job of showing how to write a secure cryptosystem. Blame the docs, blame Microsoft, blame the developer, but this program gets a bunch of things painfully wrong.
By way of bona fides and to start this off: I'm pretty sure that using PBKDF2 to generate the key and the IV for AES-CBC is broken; it produces a deterministic repeating IV for every message encrypted under a given key. Had the default mode for AesManaged been CTR, or had the developer chosen CTR mode, this would be a devastating problem; it would mean attackers without knowing anything about the key or even the encryption method could, in seconds, discover that CTR mode with a repeating nonce had been used and decrypt the messages. Fortunately, since the .NET default is CBC, it just subtly weakens the cryptosystem instead of killing it.
Why-oh-why derive the IV from the key? An idiom in modern cryptosystems: generate a random block and tack it to the front of the message.
Do you want to entrust your secret messages to developers who get this wrong? Only if you want to do that developer a favor. It's fine if you do, but I recommend trusting your real secrets to GPG/PGP.
There are significantly worse problems with this library (at least, I think; I read it for just a few minutes). Exercises for the interested reader.
Hi tptacek,
Thanks for your feedback. You're right that cryptography is not my strong point - but my hope in making the code open source is that others will help improve my code. I didn't write the AES code - I just used a popular sample, but a bad one it seems. What do you think of http://msdn.microsoft.com/en-us/library/system.security.cryp... ?
Yes, using PGP is better. Yes, I ended up implementing a poor (but much better performing) copy of PGP. It's flawed, but I did it in a few days and I think it's not broken. For the next version, I will use BouncyCastle for a true OpenPGP implementation.
Thanks for your feedback. You're right that cryptography is not my strong point - but my hope in making the code open source is that others will help improve my code. I didn't write the AES code - I just used a popular sample, but a bad one it seems. What do you think of http://msdn.microsoft.com/en-us/library/system.security.cryp... ?
Yes, using PGP is better. Yes, I ended up implementing a poor (but much better performing) copy of PGP. It's flawed, but I did it in a few days and I think it's not broken. For the next version, I will use BouncyCastle for a true OpenPGP implementation.
As far as I can tell, Microsoft says I am doing it right:
http://msdn.microsoft.com/en-us/library/system.security.cryp...
http://msdn.microsoft.com/en-us/library/system.security.cryp...
[deleted]
'It is called cryptabyte.com. It is the first, easy-to-use, web-based service to provide absolutely uncrackable security in communications and file sharing."
(emphasis mine)
"CryptAByte uses public-key encryption just like HTTPS/SSL and OpenPGP/PGP. The algorithms used are RSA for key pairs, AES 256 to encrypt messages and files, and SHA 256 for hashing."
Soooo -- like SSL and OpenPGP, but not actually OpenPGP. Yes, let's use AES directly some more and not release source code until some undefined point in the future -- that sounds like a fantastic idea!
Aren't plain PGP/GPG installables for all platforms user friendly enough already? If they're not, can we please make websites that are basically cheap shims over gpg's stdout/stdin?
(emphasis mine)
"CryptAByte uses public-key encryption just like HTTPS/SSL and OpenPGP/PGP. The algorithms used are RSA for key pairs, AES 256 to encrypt messages and files, and SHA 256 for hashing."
Soooo -- like SSL and OpenPGP, but not actually OpenPGP. Yes, let's use AES directly some more and not release source code until some undefined point in the future -- that sounds like a fantastic idea!
Aren't plain PGP/GPG installables for all platforms user friendly enough already? If they're not, can we please make websites that are basically cheap shims over gpg's stdout/stdin?
He did release the source code.
On the other hand: don't trust secrets to developers who call passphrase-based encryption "absolutely uncrackable" because theirs contains the letters "A-E-S". The block cipher function this system uses has almost nothing to do with its security, which (modulo implementation errors, of which there are several) devolves to PBKDF2.
On the other hand: don't trust secrets to developers who call passphrase-based encryption "absolutely uncrackable" because theirs contains the letters "A-E-S". The block cipher function this system uses has almost nothing to do with its security, which (modulo implementation errors, of which there are several) devolves to PBKDF2.
The developer says:
Server-side encryption means that the people running the server have access to the plaintext. The web interface simply does a PUT request that sends the plaintext to the server.
Another problem is that they are storing your private RSA key on their server. When you ask to retrieve your messages, you do an AJAX POST request, giving a token to identify they key, and your password. Presumably, the key is encrypted using the password.
If their servers are compromised, whether by hackers or by search warrant, the security of your private key depends on how good your password is. They are pitching this as bringing good security to the masses. THE MASSES SUCK AT CHOOSING GOOD PASSWORDS. If you want to bring good security to the masses, it is ludicrous to make the security of the system rest on the ability of the masses to pick a high entropy password.
In defense of the developer, it is quite possible he knows all this. In the interview the article mentions (http://libertarianstandard.com/2012/06/07/exclusive-intervie...), it is clear that this is an experiment at this stage, and it is quite possible that the developer has simply not gotten around to addressing those issues yet. The author of the article clearly has no technical knowledge of cryptography whatsoever, and so may have not understood that CryptAByte is an early stage exploration of concepts at this point.
I've got some experience designing a similar product, and I'm pretty sure that when he does get around to dealing with those issues he's going to find that it cannot be done without abandoning the idea of doing at all on the web. As far as I can see, to be secure even with users who do not pick strong passwords, you need access to the local filesystem and to a local source of cryptographically secure random numbers.
From the article (so blame the article author, not the developer):
Pure bullshit. The user has no way of knowing that the code ACTUALLY RUNNING on the site is the same as the code that is released as open source.