Search Mailing List Archives
steveweis at gmail.com
Wed Jun 19 10:06:34 PDT 2013
I have one correction to my quick look at the encipher.it code. I had
misread this line:
I did not notice the second parameter and thought this was just MACing a
key, which wouldn't make much sense. It's actually MACing the plaintext. That's
still questionable since the generally accepted practice is to
Encrypt-then-MAC. Colin Percival has a good post why:
I also noticed the verification code might be susceptible to a timing
"if (hex_hmac_sha1(key, text) === hmac)"
I was also asked offline how to compose these primitives correctly. Making
it safe and easy for developers to use crypto was one of the motivations of
Keyczar, which may be a good reference: https://code.google.com/p/keyczar/
Another option is NaCl (Networking and Crypto Library, not Native Client),
which has a simple C/C++ interface: http://nacl.cr.yp.to/index.html
And if you decide to ignore everyone telling you not to implement
server-hosted JS crypto, the Stanford JS Crypto Library is decent:
On Tue, Jun 18, 2013 at 1:05 PM, Steve Weis <steveweis at gmail.com> wrote:
> It's not safe.
> This is their bookmarklet:
> changed at any time and compromise your messages without your knowledge.
> The actual call to encrypt data is here:
> hmac = hex_hmac_sha1(key, _this.text);
> hmac += hmac.slice(0, 24);
> cipher = hmac + salt + Aes.Ctr.encrypt(_this.text, key, 256);
> They're MACing the key for some reason, then using unauthenticated CTR
> mode without an HMAC. So this is completely vulnerable to someone modifying
> the ciphertext.
> That CTR mode is implemented by this:
> nonce combined with a weak JS Math.random(). That's vulnerable to some
> attacks as well.
> Generally, I'd assume that a random crypto project you run across is
> probably not safe.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech