A New Encryption Standard of Ukraine: The Kalyna Block Cipher | Hacker News Reader

A New Encryption Standard of Ukraine: The Kalyna Block Cipher

eprint.iacr.org

15 pointsmykhal12 comments

As cipher papers go, not especially interesting. The best ones have long sections explaining each of their design decisions. This paper starts out by pointing out that GOST is much slower than AES in practice, but never acknowledges that any conventional block cipher that isn't AES is probably doomed to inferior performance (because AES is hardware accelerated).

It would be interesting to see a country adopt a native stream cipher instead of a block cipher as their standard. The performance of stream ciphers is more competitive, you lose the requirement to define 8-10 "official modes" (most of which are insecure), and stream ciphers are virtually always what you want anyways: in 2015, block ciphers mostly exist in order to be transformed into stream ciphers via counter mode.

estream II then? Did anything that came out of estream end up being used outside of proprietary product lines? Even Salsa is pretty well ignored in favor of Chacha. Are any governments using any of the estream ciphers internally?

ChaCha is just a minimally updated, hardened version of Salsa20, by the same author as Salsa20.

It's a weird question to ask, I think, because of the modern ciphers in wide use, the only non-AES cipher (heh) is an estream finalist.

I'm curious, if you use a stream cipher for file encryption how do you avoid the two-time pad problem?

You don't encrypt with the same key/nonce pair twice. All the secure block cipher modes have the same restriction; for instance, you can't CBC-encrypt multiple messages with the same key/IV.

> for instance, you can't CBC-encrypt multiple messages with the same key/IV

Is this an "always bad" thing, or does it depend on the structure of the messages and what you require to keep secret?

For example, I've seen a system that provides for storing secret strings in a database that works as follows:

Given plaintext string P, it forms an intermediate string of the form H:P, where H is a cryptographic hash of P. It then encrypts H:P using AES in CBC mode with a fixed IV and key. The resulting ciphertext is stored in a row in the database. The row ID is then used as a token to represent P.

The block size of the hash is the same size as the AES block size.

It seems to me that this is functionally equivalent to this scheme, which does not use a fixed IV:

For plaintext string P, generate an IV by taking a hash of P, xoring that with a fixed constant, and run that through AES in ECB mode using our key. The result will be the IV. Then encrypt the string :P using AES in CBC mode with that IV and our key. Store the result in the database, and also store the IV.

I realize that two identical plaintext messages will result in identical ciphertext, but in this application that is OK. If the system is asked to store a string it has previously stored, we want to recognize that the string is already stored and use the same token to represent it as before.

I don't have the brainpower to really answer this. A couple observations:

* You can design around needing a random IV by manipulating keys and message contents; as you note, the IV is a formalism. CBC doesn't simply explode if you repeat an IV.

* I am generally skeeved out by systems that use hashes of messages as parameters. Another common species of custom crypto scheme does a similar trick but uses the hash as a key.

* This also gets into the subtleties of IVs and nonces. You want an IV to be unpredictable, and you want a nonce to be unique. An IV that is the hash of a message is probably predictable (and perhaps testably so). The way CBC tends to fail with IV problems is that it turns back into ECB mode; the way ECB fails is by allowing attackers to carefully pick blocks based on combinations of known and unknown plaintext.

It would depend a lot on the system. I'm also not sure what the win here is in deriving the IV from the message, as opposed to just making it random.

Thanks for the feedback.

If a random IV were used, then there would have to be some other mechanism to detect attempts to store duplicate strings. Perhaps a table that maps hashes of already stored plaintext strings to the row ID of the encrypted string.

I don't like that, because if someone is able to steal a copy of the database, they have hashes of all the stored strings. I guess that could be dealt with by using HMAC for these hashes instead of just a plain hash.

There is a lot less discussion on the net (at least that I could find) of using IVs derived from the message than I would have expected, since it has to be about the first thing anyone thinks of when they want identical plaintext to produce identical ciphertext. The most direct discussion seems to be in Thomas Pornin's comments on his answer in this stackoverflow discussion: http://stackoverflow.com/questions/4608489/how-to-pick-an-ap...

Building around S-box lookups also seems like a weird choice in 2015. I looked and couldn't find any considerations for cache-timing side channels. There really wasn't much advice for implementers at all.

I'm not sure this is a major vulnerability in practice, but it is strange not even to mention 10+ years of cache-timing attacks against AES.

Kalyna was the result of a public competition started in 2006 [1], so it mirrors design preferences of that time. There were 4 other candidates, some were broken, and none of them seem any more cache-timing resistant than Kalyna.

[1] https://www.sav.sk/journals/uploads/0317154006ogdr.pdf

Interesting notes, I didn't realize the competition was so old. Thanks!

As a side note, I wonder how bad MAC-then-encrypt is on a stream cipher compared to a block cipher. TKIP used CRC plus Michael MIC for example.

Reply on news.ycombinator.com