
Mcrypt: Incorrect S-Boxes for GOST Cipher (2008) - Artemis2
https://sourceforge.net/p/mcrypt/bugs/35/
======
adrienthebo
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...](http://tools.ietf.org/id/draft-chudov-cryptopro-
cptls-04.html)) 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...](https://en.wikipedia.org/wiki/GOST_\(block_cipher\)#Cryptanalysis_of_GOST))
I wouldn't be surprised if GOST implementations in a number of other places
were equally broken.

~~~
tptacek
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).

~~~
Santosh83
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.

~~~
CiPHPerCoder
1\. You shouldn't _encrypt_ passwords.
[https://paragonie.com/blog/2015/08/you-wouldnt-
base64-a-pass...](https://paragonie.com/blog/2015/08/you-wouldnt-
base64-a-password-cryptography-decoded)

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

3\. It has a 64-bit block size.

~~~
Santosh83
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.

~~~
tptacek
Don't use Blowfish.

~~~
cpach
What about legacy applications that rely on Blowfish? :)

~~~
tptacek
Burn them.

~~~
cpach
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.

------
CiPHPerCoder
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...](https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong)

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

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

* Cryptographic Right Answers: [https://gist.github.com/tqbf/be58d2d39690c3b366ad](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.)

~~~
kijin
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!

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

------
acqq
Were there any changes since 2008 to the sources anyway?

[https://sourceforge.net/projects/mcrypt/files/](https://sourceforge.net/projects/mcrypt/files/)

~~~
CiPHPerCoder
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/patches/10/)

* [https://sourceforge.net/p/mcrypt/bugs/39/](https://sourceforge.net/p/mcrypt/bugs/39/)

* [https://sourceforge.net/p/mcrypt/patches/1/](https://sourceforge.net/p/mcrypt/patches/1/)

* [https://sourceforge.net/p/mcrypt/patches/6/](https://sourceforge.net/p/mcrypt/patches/6/)

------
0x0
I noticed this first on the @YOLOCrypto twitter account yesterday -
[https://twitter.com/yolocrypto](https://twitter.com/yolocrypto)

------
tptacek
Don't use GOST.

