sebsauvage / ZeroBin

A minimalist, opensource online pastebin where the server has zero knowledge of pasted data. Data is encrypted/decrypted in the browser using 256 bits AES.
http://sebsauvage.net/wiki/doku.php?id=php:zerobin
949 stars 214 forks source link

Suggestion: Stronger crypto algorithm Blowfish 448? #67

Open WAR10CKfreeworld opened 10 years ago

WAR10CKfreeworld commented 10 years ago

It has been discovered that AES has a weakness that affects all keysizes. This weakness was independently discovered by microsoft researchers but now there are reasons to believe that this weakness was inserted by the NSA.

However when the list of NSA keywords was leaked out, the word Blowfish was included. I think we should switch from AES-256 to Blowfish-448 because the fact that the NSA has this cipher as a red flag keyword indicates that they cannot crack the code.

Just saying.

ulikoehler commented 10 years ago

@WAR10CKfreeworld: Do you have a link regarding the AES weakness? I want to be absolutely sure we're talking about the same things.

Let's just assume, for a moment, AES ist totally insecure. Let's also assume, you like Bruce Schneier Algos. In this case, you'd rather use Twofish, or Serpent, or a combination thereof. Blowfish has been superseded by Twofish. As already said lease do not make the assumption a larger keyspace grants you security. While this might be true for 56-bit DES, it can not be assumed to be true for > 128 bits keysizes. Note that the keyspace does not grow linearly but exponentially.

Assuming all that, you need to implement cipher in SJCL. See http://bitwiseshiftleft.github.io/sjcl/doc/ Currently only AES is supported. ZB uses SJCL. There is nothing ZB itself can do about it. If, however, SJCL would support symmetric non-AES ciphers, I don't see a reason why ZB should not switch (in the best case, it's more secure, in the worst case, it's exactly the same). For compat reasons, one would usually use a config option for that.

The problem is, SJCL doesn't support it at the moment. I am no skilled crypto programmer, so if I implement something like that, I'd probably make it even less secure.

Making ZB use another JS crypto library is a bit more work, but should also be feasible. The problem is, I don't know one suitable for the purpose.

Furthermore, assuming you like Bruce, you should read this article: https://www.schneier.com/blog/archives/2012/03/can_the_nsa_bre.html Please note that regarding the NSA affair, nothing has really changed (it only was published, the NSA was presumably almost forever). Even if the article is from March 2012, there are IMO no indications why its assumptions should not fit. Also note that if they would be able to crack symmetric ciphers easily, they would not have gone through all the trouble of eavesdropping where the traffic is unencrypted.

Best regards, Uli

WAR10CKfreeworld commented 10 years ago

Here is the link: http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-us/projects/cryptanalysis/aes.aspx

ulikoehler commented 10 years ago

@WAR10CKfreeworld Well, they reduce the comp. complexity by about 4 times. While that may be something, it is AFAIK considered only theoretical progress and not an actual, usable security issue. Not because the attack is not applicable, but because it hardly reduces the keyspace to be searched. Even für 128-bit AES, it is simply not enough, to reduce it to 126-bit AES.