News for hackers. Stuff that matters.
Re:CryptAByte.com: Making cryptography (more) accessible to ... by tzs on Saturday June 30, 2012 @01:57PM (#4182313)
DO NOT USE FOR ANYTHING IMPORTANT!!!!! CRYPTOBYTE IS NOT SECURE AT THIS TIME!!!!!

The developer says:

   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. The
   servers hosting this application support can encrypt
   2.1 GB of data per second using the latest Intel CPU’s
   with AES support built into the chipset.
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):

   But it gets more brilliant. How can you know that you can
   really trust the service, or that Veksler himself works for
   the FBI or the like? Well, you don’t have to trust him. Veksler
   is making the entire apparatus completely open source so that
   anyone can inspect the code. He does nothing on the site that is
   not wholly open to the world, so that way anyone can know everything
   that is going on in the engine room but no one, not even the service
   owner, can know what is being communicated.
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.
Re:CryptAByte.com: Making cryptography (more) accessible to ... by HeroicLife on Saturday June 30, 2012 @02:30PM (#4182409)
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.