This project has moved. For the latest updates, please go here.

comments on the new ciphers

Topics: Technical Issues
Oct 7, 2016 at 2:20 PM
Edited Oct 7, 2016 at 2:22 PM
Hello, I have a few concerns regarding the newly implemented ciphers, especially GOST89.

1) Starting from about 2010 more and more weaknesses in GOST89 (aka Magma) have been found (especially by Nicholas Courtois). There are now attacks with complexity in the range 2^100 to 2^190 and, while none of these is usable in practice, I think it is questionable whether including it is a good idea. If you really, really don't want to use NATO-countries-based ciphers such as AES/Twofish/Serpent (although there's no reason at all not to use AES, IMHO) perhaps one could consider instead of Magma Korean ARIA or, perhaps, the new Ukranian standard Kalyna which is also quite fast.

2) More importantly, in the Veracrypt documentation it is said: `` VeraCrypt uses a modified version of Magma that uses key-dependent S-boxes instead of the static one defined in the GOST standard and that operates on 128-bit blocks thanks to a CBC-like scheme.''

This doesn't look good at all to me :( If you're using a modified version of GOST with key-dependent S-boxes and a 128-bit block size, you're not using GOST at all! As no details are provided and no one has studied this new cipher, it's security is a big, big question mark and my doubts about including GOST are even stronger because of this.

3) In my opinion the main reason for including a new cipher is speed (particularly for systems without AES-NI, eg. Raspberry Pi's), but neither GOST, Kuznyechik nor Camellia are faster than AES in software. Recent block cipherS which are much faster than AES are Threefish and Speck. Speck was developed by NSA so it's probably anathema to many but is ~3 to 10 times faster than AES in software (see Just something to consider.
Oct 7, 2016 at 8:32 PM

Thank you for these valuable comments.

Actually, GOST89 will be removed from VeraCrypt in the next release (coming in few days) following the audit that has been performed by Quarkslab.
The modification done to make it operate on 128-bit blocks (CBC-IV-NULL) preserves the 64-bit nature and thus it is problematic for XTS security proof and also handling of large amount of data. Only modes like CMC or EME (Encrypt-Mix-Encrypt) could give real 128-bit properties but the resulting cipher will be too slow.
As for the idea of key-dependant S-boxes, it was taken from GostCrypt where it was proposed by Eric Filiol as a way to protect GOST89 from known attacks. This is not a new idea and the technique used takes the output of Streebog hash of the key and mix it with the S-box using rotating xor operations. Indeed a careful study is needed for such kind of key-dependant S-box construction but the preliminary study done by GostCrypt project or us didn't indicate any weakness in GOST89 cause by such type of S-boxes.

As you noted, there two main reasons for including new ciphers: different origins for better trust and speed. For the first point, Camellia and Kuzneychik were a first step and others may be added. For speed, I agree that faster algorithm should be considered although existing ones can be made faster in VeraCrypt by optimizing their implementation. For example, version 1.19 of VeraCrypt will bring a faster Serpent implementation (2.5 factor on 64-bit machines) taken from Botan library and which uses SSE2. Thanks to this, Serpent achieves 900MB/s speed on modern CPUs which make it send only to AES for speed whereas previously it was the slowest cipher. This shows the importance of optimizing ciphers implementations using advanced CPU extensions but unfortunately not many are available as open source.
Oct 8, 2016 at 11:48 AM
Edited Oct 8, 2016 at 11:50 AM
Hello, thanks for the clarifications, that's very interesting to know. Getting rid of GOST89 is probably for the best, especially because of the issues you mentioned due to its small 64bit block size. It'd be great if you could make the present algorithms faster! As it's been mentioned somewhere else in this forum, Diskcryptor has much faster implementations and it'd be great to see them in veracrypt too. I was aware of the fast Botan bit-sliced implementation of serpent, I think it's due to Jussi Kivilinna, who developed highly-optimised assembly implementations for AES, Twofish, Serpent and Camellia, see For AES there are some other fast assemby implementations, e.g. due to Romain Dolbeau. With these implementation on recent CPUs (i5, i7) AES should run in ~1.5 cycles/byte and the other ciphers at around 10 cycles/byte [although some overhead on top of these values is probably inescapable]. In the present Truecrypt-based implementation AES runs on my i5-4460 at ~4.5 cycles/byte, Twofish at ~32 cycles/byte and Serpent at ~45 cycles/byte. As far as I remember Trucrypt uses AES-NI for performing rounds but not for the generation of the round keys, I assume for (founded?) security reasons; that probably partially explains why hardware-accelerate AES in veracrypt is fast but not quite as fast as it possibly could be.
Oct 10, 2016 at 8:43 AM

Thank you for sharing these inputs.
Indeed, DiskCryptor has better optimized implementation for algorithms using SSE and AVX but like many other publicly available optimized implementations (like some Kivilinna ones), we can't use them in VeraCrypt because of license issue: they come with GPL license which is not compatible with TrueCrypt license and Apache license used by VeraCrypt.
For now, I prefer to avoid writing optimized implementations myself and rather use well-tested and well-proved implementations. In this context, Jack Lloyd work in Botan is valuable since he licenses his work under the permissive Simplified BSD License which allows me to integrate his work in VeraCrypt.
Some implementations of Jussi Kivilinna are licensed under BSD license but not all of them (most are GPLed). For example, Camellia aesni-avx-16way and Twofish amd64-3way could be included in VeraCrypt but some work is need to adapt them to VeraCrypt interface and also to the Windows platform.
Thank you for pointing me to Romain Dolbeau work. He put his work in public domain which is very helpful. I will check his implementations.

One difficulty in VeraCrypt is the need to support 3 operating system (Windows, Linux, OSX) with 3 different compilers. This complicates integrating optimized implementations.

As for real performances, there is an overhead in VeraCrypt due to internal handling of buffer and also the use of internal thread to handle encrypting of data instead of asynchronous I/O. This affects performances to some extents. There is room for optimizations by changing internal architecture (e.g. using asynchronous I/O) but this is a huge work and for now there is no plan to do it in the near future.

Thank you again and don't hesitate to share any information or resources concerning cryptographic routines implementations.