# Which is stronger: Threefish 1024-bit, SHACAL-2 512-bit, or AES-256?

I found some App in the Google Store, and there were features only for the PRO version: Threefish 1024-bit and SHACAL-2 512-bit. Meantime, AES-256 was available in the free version of app.

So I concluded that the Threefish 1024-bit and SHACAL-2 512-bit algorithms are stronger, and I did a little research and discovered that AES-256 was invented in 2001, Threefish 1024 in 2008, and SHACAL-2 512 was also invented in 2001.

SHACAL-2 512 - I have read that this algorithm was something like "partly hacked for 50%" but for now considered as solid and unhackable.

Threefish 1024-bit - in the opinion of the authors who invented this algorithm it is more effective than AES. And it has a 2.9 security index, while AES has only a 1.7 security index (bigger is better).

• Thanks for your answers! I learned a lot, and got answer which i was interested in. --- ONE UPDATE --- – Chosenman Apr 11 '17 at 19:40
• --- ONE UPDATE --- I updated my Notepad++ and the first line of change.log was: "Fix CIA Hacking Notepad++ issue (wikileaks.org/ciav7p1/cms/page_26968090.html)." I knew that keeping your confidence data on such services like Google/Microsoft/Apple etc. drives are senseless for paranoid people because of "big brother" attention. But even simple code editors betrayed us for years)... Just was looking for solution which would be really secure. Can suggest that Windows/Mac also have such "backdoors" – Chosenman Apr 11 '17 at 19:47
• It is marketing thing about paying for PRO version which offers "better" Threefish 1024bit, SHACAL-2 512bit which are really not better than AES 256 – Chosenman Apr 11 '17 at 19:52

Neither SHACAL-2 nor Threefish are "more" secure than AES because it's a case of "meh cannot break" with all of them.

All three ciphers are unbroken and all three use keys larger than 128-bit* meaning the bigger numbers in the key size have no value except to impress people with being bigger and with the company being able to waste computation time. Also note that in the most rares cases it is actually the crypto (and especially unlikely the block cipher) that is broken but rather the implementation and especially the data handling implementation.

Now for a bit of discussion on each cipher:

• SHACAL-2. It is based on SHA-2's compression function and from what I can tell turning it into a block cipher was a case of "we did it because we could". It's practical deployment is absolutely negligible and cryptanalysis results are sparse, so I wouldn't trust it more than AES.
• Threefish. Threefish was the block cipher underlying the Skein submission to the SHA-3 competition. It has some well-reputed names behind it and is a very useful tool block-cipher with a large block size that is especially hardened against related-key attacks and side-channel attacks. I would actually prefer Threefish over AES if you don't have a well-hardened implementation of AES available and you are on a 64-bit platform and you don't have hardware-accelerated AES available. This is because Threefish only uses additions, rotates and XORs (ARX) which makes it quite easy to implement securely and with solid performance. Analysis-wise it has seen quite a bit during the SHA-3 competition and a bit afterwards, but as Skein wasn't selected it hasn't seen much analysis since.
• AES. AES is an excellent block cipher which has with-stood nearly two decades of intense cryptanalysis. Not only hasn't it been broken in this time, but we have also figured out how to implement it securely and it has wide hardware support these days, making it the performance- and security-wise best choice if available. If not, using a more modern ARX based cipher is also appropriate, but especially on a modern phone secure AES implementations should be available.

On this topic, also see the mandatory blog post by Matthew Green.

* If you believe that large-scale quantum computers will exist at some point, you need 256-bit symmetric keys to force $$2^{128}$$ quantum operations (thanks to Grover's Algorithm) which all three cipher support.

• Thank you, your answer seems the most relevant to my question, I understood those marketing "laud names" such as "Threefish 1024bit" are not really more effective in sense of security. – Chosenman Apr 11 '17 at 20:00

There is more to a question like this than just has the algorithm been broken. The other and equally important question is how was the encryption algorithm implemented? Who implemented it and was it reviewed to ensure the implementation was good. Getting crypto right is very difficult and making errors is very common, even for widely used and well know software, openSSL for example have had some very significant problems with their crypto implementation

http://thehackernews.com/2016/05/openssl-vulnerability.html

The reason this really matters is once you encrypt something if it is made public, especially for data at rest, the encryption has to protect that data until protecting confidentiality of the data is no longer of value. which could be your entire life or longer if its very personal information. If a flaw is found the data is no longer protected. Some encryption implementations can be certified as correctly implemented, AES for example can be reviewed against the NIST FIPS 197 standard

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf

So another consideration is can the implementation of the encryption algorithm be verified as good. If a company goes to the trouble of doing this then for me I can have confidence that they care about their software. An good example is WinZIP, they state publicly that their implementation for their zip file encryption has been reviewed and is compliant with the FIPS 197 standard.

kb.winzip.com/kb/entry/65/

(sorry, I don't have enough reputation points to have this as a HTTP link)

For example is I was looking at some software which included file encryption. I wanted to work out how it was encrypting the files as it wasn't documented. I checked the files it installed and the were using 7Zip to zip and encrypt the files they were processing. However the 7Zip dll file they were using was over 10 years old, what does that say about a software company who has continued to use a version of software which is that old, 7Zip most recent update was end of last year, however they are still using a very old version. (NOTE: To be clear this is not an issue with 7Zip, it is another company using a very old version of 7Zip dll file)

• Note that "compliance with FIPS 197" doesn't mean anything for security, it just means that they managed to correctly implement the standard (ie it functionally works). Also note that it is in fact easier to securely implement Threefish than AES if you don't have hardware support because it doesn't suffer from many side-channel attacks due to being an ARX design. – SEJPM Apr 9 '17 at 13:23

AES is enough, but the security of the encrypted data depends almost of all about how you want to use. You can use AES in CBC mode and you are ok.

• Only using CBC mode is really bad advice and will not protect against all sorts of standard attacks, especially against chosen-ciphertext attacks. It should always be recommended to use an authenticated encryption mode (such as GCM). This is why I downvoted this answer. – SEJPM Apr 9 '17 at 13:19

The answers above may look like a spaghetti of different concerns for many readers. Let's sort it out.

1. Security, cypher strength. The statement of @SEJPM is misleading. This is like to say "100 googols is not greater than 1 googol, because even 1 googol is too big". Dont't mix key length and cypher strength. If the key length = 128 bits, it doesn't mean one needs 2^128 keys to break it. For a naive brute force breaker, yes, that would mean 2^128 attempts. But for an advanced breaker in a particular context that can mean essentially less keys that need to be tested. Nevertheless, the correlation does exist, the longer the key, the more attempts are needed, the more secure the cypher is. That's why ignore the "meh cannot break". Of course, Threefish with 1024 bits key is more secure than AES with 256 bits key.

2. Resources. Are you going to encrypt terabytes of data each day? Then the statements of @SEJPM about resources may be relevant for you. If you are going to encrypt your emails or your chat messages only, you may not even notice any changes in resource consumption. It depends on your use case.

3. Goal of encryption. Consider what are you going to achieve with encryption. Who are you going to hide the data from? From somebody who occasionally gets access to your data, e.g. on a network share or in a cloud backup? From somebody who intentionally wants to get your data? From the government? Some of them have much, some have few resources to break the encryption. How long want you keep your data secret - 1000 years, 10 years, 1 year, 1 month? What will be the price of what you lose if your encryption is broken? Will you lose \$1000000 contract, \$100 or \\$10? In one case Threefish 1024 may be needed. In another case even the old 3-DES may be sufficient.

4. Encryption and smartphone? This is an oxymoron. Google can access your smartphone at any time. Many processes can access your data on the smartphone, from files in the file system to the keyboard. Again, consider what are you going to gain with encryption. If the price of disclosure is really high, you are not going to use smartphone for encryption.

5. Marketing. Of course marketing is important in the mentioned app. No, they don't lye about the encryption strength. Threefish 1024 gives really more security than AES 256. The marketing trick is to make you feel that you need stronger encryption where as in the reality even not only AES256, but even 3-DES may be sufficient. Again, consider points 3 and 4 above.