Mcrypt: Incorrect S-Boxes for GOST Cipher (2008) | Hacker News Reader

Mcrypt: Incorrect S-Boxes for GOST Cipher (2008)

sourceforge.net

31 pointsArtemis217 comments

GOST seems like an oddball; it's been around for a long time but doesn't seem like it got any traction outside of Russia. To the best of my knowledge GOST cipher suites were never accepted into TLS, there was a draft (http://tools.ietf.org/id/draft-chudov-cryptopro-cptls-04.htm...) but it expired in June 2009. Given that it's not in TLS, isn't widely used, there aren't good reasons to use GOST over AES, and GOST is considered "deeply flawed" (https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanaly...) I wouldn't be surprised if GOST implementations in a number of other places were equally broken.

Three reasons we sometimes see GOST (there are probably lots more; these are just the ones I'm aware of):

* It's a block cipher with a large key that was well-known in the mid-90s, when TripleDES was the best-practice.

* Its big competitor for the time, IDEA, had IP issues, so if you were looking for "natively better than DES", you might land on GOST.

* Schneier wrote about it in Applied Cryptography (blech; spit).

I think similar logic applies to why we still see RC4; when it was finally revealed, after having been an RSA, Inc trade secret for years, it was the only regularly-available stream cipher with any kind of pedigree. Since 99 times out of 100 when you're encrypting data with a computer you're really asking for a stream cipher, RC4 got a lot of use.

Obviously: don't use GOST or RC4 or TripleDES or IDEA (or Blowfish).

May I ask why you include Blowfish in the blacklist? I'm relatively new to the technical side of computers but I use Blowfish (as implemented in GPG) to encrypt my password and other files.

1. You shouldn't encrypt passwords. https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

2. Blowfish and bcrypt are totally separate, if that's what you meant.

3. It has a 64-bit block size.

Oops I think I was a bit unclear. I encrypt my passwords file (which contains other information too, like credit card details and so on), much like how password managers like keepass do, but I do it manually with gpg set to use the blowfish cipher.

Don't use Blowfish.

What about legacy applications that rely on Blowfish? :)

Burn them.

Haha, allright then. I was recently shopping for a backup system and I guess I made the right choice when I avoided the one that made use of Blowfish.

It's considered "deeply flawed" by one (rather famous) cryptographer. And by "deeply flawed" he meant [1] that if the attacker has 2^64 plaintext/ciphertext pairs, he can then attack ciphertext 256 times faster than by bruteforce.

The relevance of this "deep flaw" to a realistic attack is unclear. (The attacker will need at least 0.25 zettabyte storage for those plaintext/ciphertext pairs - and don't forget about the time and bandwidth for obtaining them...)

TL;DR: GOST 28147-89 is an old cipher. You shouldn't use it today because there are newer and stronger algorithms available. But for its time, it was a brilliant algorithm, and attacking it still requires NSA-level resources.

And if you are interested and can read Russian, see [2] for a summary of known ways to attack GOST.

[1] http://eprint.iacr.org/2011/211 [2] https://ru.wikipedia.org/wiki/Криптоанализ_ГОСТа_28147-89

This is indeed pretty terrible. It indicates that this library was not adequately studied by security experts at the time it was abandoned.

If you're writing code with libmcrypt (for example, in PHP), strongly consider switching to OpenSSL or, if the upcoming RFC passes for 7.1, libsodium. (An RFC passed this week that will deprecate then remove libmcrypt support for PHP.)

Further reading:

* If you're typing MCRYPT into your PHP code, you're doing it wrong: https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...

* Mcrypt deprecation/removal RFC (accepted): https://wiki.php.net/rfc/mcrypt-viking-funeral

* Libsodium RFC (soon): https://wiki.php.net/rfc/libsodium

* Cryptographic Right Answers: https://gist.github.com/tqbf/be58d2d39690c3b366ad

(Note: Although libmcrypt is terrible, it's worth noting that PHP's own ext/mcrypt code, mostly mcrypt_create_iv(), is actually not bad.)

I'm a regular contributor to a FOSS project that supports fairly old versions of PHP.

We use defuse/php-encryption where possible, but fall back to an mcrypt wrapper on older platforms. The wrapper implements key splitting, PKCS#7 padding, HMAC, and constant-time string comparison in a way that is fully compatible with defuse/php-encryption, and we have unit tests to ensure that data encrypted with the former can be decrypted with the latter and vice versa. Still, I'm not thrilled by having to keep this wrapper around. Our next major version will finally drop support for PHP < 5.5, and I'm very much looking forward to it.

On the other hand, using OpenSSL doesn't feel all that safer, either, given its terrible codebase and frequent vulnerabilities. Can't wait for libsodium!

None of the OpenSSL vulnerabilities that were published in the past few years affected its AES implementation.

Were there any changes since 2008 to the sources anyway?

https://sourceforge.net/projects/mcrypt/files/

Short answer: No.

Long answer: Yes, there are community-provided patches available on the SourceForge project, but they were never merged and a new release was never tagged by the project team, so effectively no.

* https://sourceforge.net/p/mcrypt/patches/10/

* https://sourceforge.net/p/mcrypt/bugs/39/

* https://sourceforge.net/p/mcrypt/patches/1/

* https://sourceforge.net/p/mcrypt/patches/6/

I noticed this first on the @YOLOCrypto twitter account yesterday - https://twitter.com/yolocrypto

Don't use GOST.

Reply on news.ycombinator.com