Kalyna Block Cipher

Kalyna is a block cipher that became a Ukrainian national standard in 2015. It supports block and key sizes of 128, 256, and 512 bits. Its structure looks like AES but optimized for 64-bit CPUs, and it has a complicated key schedule. Rounds range from 10-18, depending on block and key sizes.

There is some mention of cryptanalysis on reduced-round versions in the Wikipedia entry. And here are the other submissions to the standard.

Posted on March 28, 2017 at 6:26 AM • 84 Comments

Comments

ThothMarch 28, 2017 6:53 AM

They should have just stuck to existing and well studied ciphers like Twofish, Serpent and ChaCha20 instead of trying to re-invent the wheel like many countries with their "National Algorithm" and in the end, everyone still stuck to AES and DES ciphers despite having "National Algorithm".

HowardMarch 28, 2017 7:11 AM

I like Twofish, Serpent and ChaCha20. I still see Blowfish and 3DES popping up every now and again.

As it happens Apple removed 3DES as a default cipher in watchOS 3.1.3* but in iOS 10.3** they added it to their SCEP client (DES was deprecated); it's still extremely popular in the credit card world though.

* https://support.apple.com/en-us/HT207487
** https://support.apple.com/en-gb/HT207617

I'm also fond of cascades which might have been a solution if the Ukrainian government was looking for added security by developing their own, more modern (but not widely-studied) cipher.

A 512-bit key size and support for 64-bit CPUs is promising but I dislike complicated key schedules because there's scope for error. I'll study the document in due course.

I've got nothing against modern ciphers and we need to keep developing them because Rijndael (AES) may eventually no longer serve us well. For that reason I'm an advocate of post-quantum cryptography although developing effective ciphers is difficult without a crystal ball.

WmMarch 28, 2017 7:12 AM

I am wondering how reliable the author names are. Seven names end as:
kov, rov, sov, gov, yov, nov, and lov. To be a bit different, there is one sev, also two Gorbenko. Could this be fake block cipher news?

Vesselin BontchevMarch 28, 2017 7:35 AM

@Wm in many Slavic languages, the ending "ov"/"ev" means belongingship (for male; "ova"/"eva" for female). It's similar to how "Johnson" basically means "the son of John". My family name ("Bontchev") basically means "Bontcho's", with "Bontcho" being the first name of some distant male ancestor of mine. So, these Ukrainian family names are perfectly normal.

TreblaMarch 28, 2017 8:02 AM

Instead of developing yet another algorithm they should stick to well tested ciphers that have survived many years of scrutiny.

ScissorsMarch 28, 2017 8:02 AM

One of the prerequisites for submissions to the standard:
"A proposed solution must not have any trapdoor and should not be suspected to have one."
Is it standard practice to include this? There seems to be a lot of room for interpretation and manipulation.

RomanMarch 28, 2017 8:18 AM

Ideas on Kalyna design rationale (including preference for S-box based construction over ARX transformation) are published in Ukrainian here: http://jrnl.nau.edu.ua/index.php/ZI/article/download/8789/10813 ; as for now there is no English translation, unfortunately. Independent cryptanalysis results are also available on eprint.iacr.org

Authors can be reached via e-mails from the Kalyna paper ( https://eprint.iacr.org/2015/650.pdf ); some of them also have profiles in social networks. They're real people )

My InfoMarch 28, 2017 8:54 AM

I am so happy to see this blog return to the subject which first attracted my interest.

The entire process about the selection of AES left me rather disheartened, especially with the apparent conclusion that AES is "the" block cipher, "good enough" for all practical purposes, even government secret and top secret use, and we need study no other.

Excessive warnings and admonitions were issued about cryptography's being a black art: "Don't roll your own cipher; don't even think about it. You're an idiot if you try it."

Suppose I did develop my own unique cipher that was theoretically weaker than the prevailing standard. It would still take some manual effort to crack it on the part of NSA, which has for the most part seemingly given up all interest and ability in true cryptanalysis, in favor of exerting political control to weaken the hardware and software of the endpoint computers and devices which have access to the plaintext.

The "cypherpunks" whose online culture was obliterated by the MAFIAA years ago did not so much have anything to hide, but would tend to experiment with some computer cipher or other in a what-if scenario. Or put something unusual or bizarre out there, and try to find out if anyone could crack it.

I don't like Chicago wheat futures or banana monocultures. Why should I like cipher monocultures or buy into Rijndael/AES as the be-all and end-all of computer ciphers? I am especially interested in the runners-up to some of these contests. SERPENT, for example.

https://www.cl.cam.ac.uk/~rja14/serpent.html

Almost certainly even stronger than Rijndael which was selected as AES, it was apparently rejected because it required excessive computation.

=============

I am very curious about the development of a Ukrainian standard. Do the Ukrainians believe that Vladimir Putin is able to break AES? Or, in the worst of all possible worlds, has the Ukrainian process been actively subverted by Putin's agents?

keinerMarch 28, 2017 8:58 AM

... I believe EVERYBODY (outside US) is more comfortable nowadays with non-US security solutions.

Who?March 28, 2017 9:24 AM

@ keiner

I would say most people in the U.S. are more comfortable with non-U.S. security solutions too.

AnuraMarch 28, 2017 9:26 AM

Given the progress made with ARX ciphers, I'm curious why they chose to use s-boxes when they are slow and potentially introduce side channel attacks. Seems like a minor security improvement over AES at the expense of performance (and I doubt Kalyna will be able to make much use of AES-NI), when ciphers like ChaCha20 are fast in software and potentially more secure.

hermanMarch 28, 2017 9:31 AM

"non-US security solutions" - like Rijndael/AES which is from Belgium? Anyhoo, I'm glad that some people are working on different ciphers. The old Soviets have always been good at it.

My InfoMarch 28, 2017 9:37 AM

@keiner, Who?

... I believe EVERYBODY (outside US) is more comfortable nowadays with non-US security solutions.

I would say most people in the U.S. are more comfortable with non-U.S. security solutions too.

Our situation in the U.S. is not so different from that in Ukraine or other Russian satellite nations. We have the Democratic white nationalists and the Republican Putinists. They pretend to oppose each other, and we find out that all the meanwhile they've been scratching each other's back at city hall.

Blacks, Jews, LGBT, and other minorities are just thrown under the bus in this two-party system. Adjudicated as mental defectives and thrown into mental hospitals which if things go as planned are then set afire by government henchmen.

@herman

"non-US security solutions" - like Rijndael/AES which is from Belgium? Anyhoo, I'm glad that some people are working on different ciphers. The old Soviets have always been good at it.

Sure. Right now, like everyone else in the U.S., I am suffering from acute putinitis of the brain, and I need R&R.

ThothMarch 28, 2017 9:39 AM

ChaCha20 ciphers are all over Github and Interwebs even with it's own RFC standard (RFC-7539).

I even ported ChaCha20 to 16-bit JavaCard quite many months back and released the source on my Github page :) .

There's NaCL and BouncyCastle that supports ChaCha20 and even OpenSSL supports ChaCha20 which they could have just adopted right away. ChaCha20 which is designed to resist certain classes of side-channel attacks is probably more suitable for modern security applications considering that during the time of AES competition, the likes of side-channel attacks are less known and thus may not have been actively incorporated into those ciphers back then.

My InfoMarch 28, 2017 9:43 AM

@Scissors

One of the prerequisites for submissions to the standard:
"A proposed solution must not have any trapdoor and should not be suspected to have one."

Is it standard practice to include this? There seems to be a lot of room for interpretation and manipulation.

My concern is that this would have left more than enough wriggle room for Vladimir Putin to veto any proposed standard.

My InfoMarch 28, 2017 10:09 AM

@Thoth

ChaCha20 is from D.J. Bernstein. That is exclusively a one-man show. I have yet to see independent analysis of any of his ciphers from anyone outside his college fraternity.

WinterMarch 28, 2017 10:27 AM

@My Info
"Suppose I did develop my own unique cipher that was theoretically weaker than the prevailing standard. It would still take some manual effort to crack it on the part of NSA, which has for the most part seemingly given up all interest and ability in true cryptanalysis, in favor of exerting political control to weaken the hardware and software of the endpoint computers and devices which have access to the plaintext."

Sounds reasonable, until you realize that the "roll your own" solutions have a tendency to fail catastrophically. The tried-and-tested solutions tend to fail "gracefully" (not always). Supposed cracks usually require lots of effort and computing power and warnings are going out a long time before the fact (see, e.g., md5 and sha1, single DES might be a counter example).

And the NSA is not the only agent trying to crack crypto.

My InfoMarch 28, 2017 10:42 AM

@Winter

Sounds reasonable, until you realize that the "roll your own" solutions have a tendency to fail catastrophically.

See, this is where the "not having anything to hide" part comes in. The cypherpunks weren't drug dealers, smugglers, or child pornographers. They didn't have anything like that to hide, and in fact they'd rat that sort of criminal out every chance they got.

No, no one wants to risk felony or other serious criminal charges on "roll your own" solutions. What I value here is the lost academic freedom to "roll my own" solutions.

Unfortunately the catastrophic failure modes we're talking about here are not from one's crypto being broken in the sense that plaintext or keys are being discovered but from the barrel of Dan Bernstein's pistol and from some medieval university mace brought out of the back closet of the frat house for the "occasion."

Megan PrentyMarch 28, 2017 11:23 AM

Jokes on you, when hackers suddenly crack AES, RSA, and TwoFish, the whole world would be in a global crisis except Ukraine, that will be safe with their Kalyna standard.

dvvMarch 28, 2017 12:27 PM

@Megan Prenty, the joke is on you as you won't ever see those enlightened times. Besides, the Russians have their own crypto standard, too.

Clive RobinsonMarch 28, 2017 12:40 PM

@ Anura,

I'm curious why they chose to use s-boxes when they are slow and potentially introduce side channel attacks.

Timing side channel attacks were the big problem with the AES competition.

The NSA effectively set the rules for the AES competition and NIST just rubber stamped various parts because they appeared reasonable.

Three things were problematical. Firstly the NSA would have known in considerable depth the problems with side channels, especially time based side channels. However they did not in any way take measures to prevent the risk (which is maybe why they still only regard it as secure for "data at rest").

In fact the NSA appear to have gone to some lengths to make sure time based problems would occure. As I've mentioned a few times in the past there is an issue with computer based security. It's "Efficiency-v-Security" in the general case --ie unless you take special measures-- the more efficient you make a process the more transparent it is to data leaks via time based side channels. Likewise the faster you make an algorithm run the more likely it is to have time based side channels.

One aspect of the competition was that entry submitters had to provide various implementations that would be freely available to all. Further these implementations had to be both efficient and fast. Obviously the two combined was a recipie for disaster. And it would appear that the NSA's hand was behind both of those choices, without any warning being given about side channels (even though atleast one researcher mentioned it).

The not unexpected result was that the code for the various finalists was downloaded by many and put directly into code libraries.

The result was and still is practical implementations of AES hemorrhaging secret information via time based side channels either to other processes on the same computer or onto the network interface and so off out into the world...

If you look back far enough on this blog I gave clear warnings that AES should only be used "off-line" with a second computer being used to communicate the ciphertext. But it was not realy listened to then, or apparently now as there are still embedded products being developed to run "on-line" that have bad AES code libraries...

I can imagine just how pleased this little bit of "finessing" must have made various people within the NSA... High fives all around.

Thus all new crypto algorithms need to be examined to see if they can be practically built to avoide side channels.

DanielMarch 28, 2017 12:58 PM

re: efficiency vs security

The issue of efficiency vs security works both ways. Let me draw on an example from the law. Currently, in the USA, it is well recognized that more than 90% of all criminal cases end with a plea bargain. Further, it is recognized that the system has become financially dependent on this reality. The consequence being is that if everyone stopped pleading guilty and instead went to trial the entire system would freeze because there is no manpower or funding to try all the case, not even 25% of them.

So same situation is true for crypto. Anyone who rolls their own crypto is at one level a fool because anyone can make a standard they themselves cannot break. Yet imagine if the world of hurt the NSA would be in if it had to confront one million different kinds of crypto. Each one individually might be trivial to break but collectively they would freeze the agency. There simply isn't the manpower or the funding to go through a million cases and break each individually.

So there is a strong argument that with crypto standards, whether they be set by NIST or the Ukrainian government, makes individuals stronger while making the collective weaker whereas if everyone rolled their own the individual cyphers would be weaker but the collective would be stronger.

My InfoMarch 28, 2017 1:39 PM

@Megan Prenty

Jokes on you, when hackers suddenly crack AES, RSA, and TwoFish, the whole world would be in a global crisis except Ukraine, that will be safe with their Kalyna standard.

So far all of academia has been unable to prove PNP.

Now consider the basic block cipher problem.

  • C = Ek(P)
  • P = Dk(C)

The encryption and decryption functions E and D are easily computable, and they reverse one another, given the same key k. In general we have no proof or positive basis to believe that it is impossible to discover or compute the key k given both the plaintext P and the ciphertext C satisfying the equations above.

Suppose for each bit or the plaintext or ciphertext, for each bit within the inner workings of the encryption algorithm, and for each bit of the key, we assign a floating-point variable representing the logit function f(p)=log(p/(1-p) of the probability p of that bit's being true rather than false.

The bits that are known have an infinite logit value forced to remain constant, and the unknown bits are randomized or set to zero logit. Then there might be some iterative or randomized or even quantum annealing algorithm that might be applied to this setup. When all the logit values have diverged to +∞ or -∞, a solution for the key would be obtained, given the ciphertext and the plaintext.

Or apply the same algorithm to a hash believed to be one-way and difficult to invert.

ab praeceptisMarch 28, 2017 1:48 PM

I don't care. For one I trust *nothing* from ukraine. Moreover I don't see any urgent need for yet another block cipher. (That said, no, I do not think that kalyna is shitty)

We are right here, in this very blog on the site of the creator of some excellent sym. crypto. blowfish is still standing well and solid and for those who prefer more modern ciphers, well there is more fishes ...

There is djb's salsa/chacha which are well designed and engineered (an important aspect!), well analyzed and tested.

For those who don't trust djb or dislike, I quote, "one man shows", there are alternatives. Sidenote: If you don't like one-man shows you'd have to let go massive bodies of math.

And, of course, there is AES. While coming from highly reputable Belgians I agree with those who feel that being a nist standard AES feels smelly and stained. That said, objective analysis done so far show AES to be healthy (and no, I do not care about occasional tiny minor successes in attacking it. That's just normal and to be expected).

Plus, of course, tons of others. So there simply is no need for kalyna other than maybe for internal purposes within ukraine.

What worries me much more is pub. crypto and PKI. And no, my worries isn't quantum computers just around the corner. It is math. Mathematicians getting an ever better understanding about Riemanns conjecture and closing in is a joy on one hand but a major worry on the other.

And there isn't any well researched, trustworthy, and practically real world useable alternatives yet, which leaves us in a rather unpleasant state.

That said, we probably shouldn't be too worried about ciphers because PKI is but a carton house on a rainy day ...

Finally, as indeed someone came up with that idiocy: No, Vladmimir Putin is not behind Kalyna nor would or could he veto it. In case someone didn't get it yet: Russia (whose president Putin is) and ukraine are not exactly friends.

My InfoMarch 28, 2017 2:21 PM

@ab praeceptis

I don't care. For one I trust *nothing* from ukraine.

You shouldn't have to. That's not the point of an open standard.

There is djb's salsa/chacha which are well designed and engineered (an important aspect!), well analyzed and tested.

For those who don't trust djb or dislike, I quote, "one man shows", there are alternatives. Sidenote: If you don't like one-man shows you'd have to let go massive bodies of math.

I don't care if Daniel J. Bernstein is likable or trustworthy, and I shouldn't have to. That's not the point, either. Precisely those "massive bodies of math" are so sorely in need of independent review from outside the frat house. If no one but Daniel J. Bernstein himself can do the math, then it's time to clean the chips and dip off that sofa in the frat house TV room and go for some healthier food.

No, Vladmimir Putin is not behind Kalyna nor would or could he veto it.

But there is the possibility that he vetoed (and stole for his own use) another, better algorithm, that we are not allowed to know about.

ab praeceptisMarch 28, 2017 2:49 PM

My Info

Am I right assuming you wanted to be funny and make jokes?

Precisely those "massive bodies of math" are so sorely in need of independent review from outside the frat house.

Good luck. When will you begin to re-do the work of Euler, to name just one "one man show"?

If no one but Daniel J. Bernstein himself can do the math, then it's time to ...

That is not the case. As I said, djb's work was reviewed by quite some peers. One of those, "ruedi" (a german prof often featured by CCC) likes to say "What's so great about it? Everyone should be capable to chose sensiblel weierstrass curves".

[Vladmimir Putin] ... But there is the possibility that he vetoed (and stole for his own use) another, better algorithm, that we are not allowed to know about.

Uhm, how exactly would the russian president veto a ukrainian algorithm?

And yes, he could steal a ukrainian (or other) algorithms and he also could use a foreign algorithm as a base for a better one. So what?

For one that happens every other day on this planet - very rarely with Vladimir Putin being behind it.
Moreover: Why should Putin steal algorithms? The Russians aren't exactly poor in term of math incl. crypto and there are plenty of freely available crypto algorithms available all over the globe.

I suggest you calm down, get a somewhat more realistic understanding, and stop seeing Vladimir Putin everywhere.

BTW, The Russians - just like most others - publish their algorithms and nail them down in Gost standards (similar to nist).

Bruce SchneierMarch 28, 2017 2:55 PM

"I believe EVERYBODY (outside US) is more comfortable nowadays with non-US security solutions."

Which is why we like AES. It's Belgian.

Bruce SchneierMarch 28, 2017 2:56 PM

"One of the prerequisites for submissions to the standard: 'A proposed solution must not have any trapdoor and should not be suspected to have one.' Is it standard practice to include this? There seems to be a lot of room for interpretation and manipulation."

I read this as: no suspicious constants, like DUAL_EC_PRNG.

Bruce SchneierMarch 28, 2017 2:58 PM

"Sounds reasonable, until you realize that the 'roll your own' solutions have a tendency to fail catastrophically."

Crypanalysts always need new targets.

WinterMarch 28, 2017 4:27 PM

@my info
"In general we have no proof or positive basis to believe that it is impossible to discover or compute the key k given both the plaintext P and the ciphertext C satisfying the equations above"

I think you did not formulate this well. The algorithm to decrypt a crypttext message with an unknown key it trivial: Itterate over all possible keys.

That solution is obviously not polynomial in the key length. We will only know for sure whether a polynomial algorithm exists (or not) when NP=P is (dis)proven.

Although I suspect that even with a proof, we will still not know for sure.

My InfoMarch 28, 2017 4:29 PM

"I believe EVERYBODY (outside US) is more comfortable nowadays with non-US security solutions."
Which is why we like AES. It's Belgian.

Not to say there aren't good things to come out of Belgium. In particular the research of the criminologist Nicolas Desurmont.

This research is relevant to the stalking and harassment I continually experience in the U.S. My experiences are corroborated by the testimony of Ted Gunderson, former Special Agent in Charge for the FBI, in an affidavit made about a month before his death.

Howbeit, I'd rather discuss the cryptography itself on its technical merits, than on political grounds, which is by now an old trick of the European Übermensch to silence and exclude "amateurs" from general discussion of cryptography.

... no suspicious constants, like DUAL_EC_PRNG.

Exactly! Now if they had said it like that in the first place, they wouldn't have left that political wriggle room for the Putinistas.

Crypanalysts always need new targets.

Amateurs as well need new targets. Rock star crypto is not always the best crypto. Not everyone is going to be a star football player. This is no reason, for example, to outlaw the game of football except for permitted games between licensed franchise teams in official stadiums, and condemn everyone who is not a "professional" to laziness on the couch.

The caveat for "professionals" here is that the proposed cryptological scheme rather than the human who invents it should be the target, and for open cryptanalysis rather than MAFIAA-style classification and censorship, which is sadly all too often the case.

It's just that from the paucity of bona fide open research over the years, I deduce that the research is being suppressed and the researchers oppressed.

My InfoMarch 28, 2017 4:31 PM

@Winter

I think you did not formulate this well. The algorithm to decrypt a crypttext message with an unknown key it trivial: Itterate over all possible keys.

You're right. I left too much wriggle room in the interpretation. I forgot the requirement of reasonable time and space.

WinterMarch 28, 2017 4:43 PM

@my info
"Not to say there aren't good things to come out of Belgium. In particular the research of the criminologist Nicolas Desurmont."

When I hear people praising good things from Belgium, neither criminology nor cryptography are common items on the list.

I think a short vacation in Belgium would do you good.

And as you seem to be interested in LGBT matters, Belgium's previous prime minister was gay. So that should not be a problem.

ab praeceptisMarch 28, 2017 5:02 PM

My Info

Pardon me for getting quite frank but you have made a series of clueless and utterly politicised comments (plus some "we transsexuals are being discriminated/hunted/persecuted" annotations that aren't exactly within the main interest here).

And now you are abusing Bruce Schneiers comment as if he was confirming your position? Sorry but this gets ridiculous.

(you, responding to Scissors)
Is it standard practice to include this? There seems to be a lot of room for interpretation and manipulation.

(Bruce Schneier, presumable responding to Scissors)
I read this as: no suspicious constants, like DUAL_EC_PRNG.

Which is the obviously correct understanding.

(you, recurring on Bruce Schneiers statement)
Exactly! Now if they had said it like that in the first place, they wouldn't have left that political wriggle room for the Putinistas.

Who is "they"? And what the f*ck is Putin(istas) to do with it?

I have not yet seen any Putin or Putinistas involvement in crypto or crypto standards or rules for crypto standards. Maybe you can elucidate me and provide links to Putin(istas) engaging in any not insigificant way in crypto standards, particularly in making sure there is "wiggle room".

La géocriminologie en contexte de gang-stalking (The geocriminology of gang stalking)

Can you explain what that is to do with crypto?
Btw. might it be the case that a considerable parts of you being stalked is to do with you stalking others with your not at all asked for and utterly out of context "I'm a transsexual" sh*t?

I'd rather discuss the cryptography itself on its technical merits, than on political grounds, which is by now an old trick of the European Übermensch to silence and exclude "amateurs" from general discussion of cryptography.

Yet another statement of you that is just ridiculous as *you* are one of the major offenders here in frequently politicing crypto, e.g. by "Putin" allusions, while at the same time making doubtful (to put it *very* diplomatically) statements on the technical side.

Now, before you tick out and feel yet another hunt against you, kindly consider the following:

I don't care a rats a** whether you are hetereo, homo, male, female, or whatever in between or outside of established patterns. I simply don't care and I wish you a happy life as whatever.

But this blog here is about security and I happen to care about security. In case you feel attacked let me assure you that the reason is not me being a european "Übermensch", nor you being a transsexual but simply because you behave like an unnerving idiot basically begging to get a hard reminder.

rMarch 28, 2017 6:15 PM

ab,

Go easy on the kid please, you are not an uber man and have never been one. My Info has volumes upon volumes our issues et play and whether or not he is playing in the deep end unsupervised currently we all have something to contribute, unique views positions and skills that each one of us don't necessarily fathom. He's railing and reeling against and from the abuse of our psychosocial playground.

What kind of man would poke a savant in their third eye?

Especially a security or cryptography researcher.

Shame.

Dirk PraetMarch 28, 2017 6:50 PM

@ Thoth

There's NaCL and BouncyCastle that supports ChaCha20 and even OpenSSL supports ChaCha20 which they could have just adopted right away.

So do strongSwan, KeePass (off-line password manager) and more recent versions of OpenSSH (6.5+). Even comes before AES on my Ciphers line: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr .
Chrome and Firefox also support chacha20_poly1305 (since v47).

@ Bruce

I read this as: no suspicious constants, like DUAL_EC_PRNG.

I suppose you meant Dual_EC_DRBG ?

@ Winter

When I hear people praising good things from Belgium, neither criminology nor cryptography are common items on the list.

Never heard about this Desurmont character. Whenever people ask in a scientific context, I usually refer to folks like François Englert (one of the guys behind the Higgs boson), George Lemaitre (Big Bang theory; not the tv show), Mercator (cartography), Ernest Solvay (ammonia), Zenobe Gramme (dynamo), Leo Baekeland (bakelite), CERN's Jorgen d'Hondt and indeed Vincent Rijmen and Joan Daemen. Daemen, by the way, was not just involved in AES (Rijndael), but also co-designed Keccak, that became SHA-3 (defeating @Bruce's Skein).

In an art context, that would be painters from the Flemish Primitives over Rubens, Van Dijck and Magritte to contemporaries like Luc Tuymans. And, once again: there is no such thing as French fries. They're Belgian fries.

@ r

He's railing and reeling against and from the abuse of our psychosocial playground.

Perhaps so, but it's getting irritating, especially in times when our host just asked everyone to stay civil and on topic. Which neither ranting about Putin or gender issues is. As much as I condemn LGBTQ discrimination (or worse), there's no reason to give them any special privileges either on a platform that has nothing to do with it. Otherwise next thing you know we have an albino bringing up African superstition in every thread.

3/4 * the lulzMarch 28, 2017 7:26 PM

@Moderator

Not saying your attention is necessary, but... a highly visible well documented policy would be appreciated!

My InfoMarch 28, 2017 7:52 PM

@r

He's railing and reeling against and from the abuse of our psychosocial playground.

He, he, he.

While most researchers take citations with the correct gender for granted.

I have not yet seen any Putin or Putinistas involvement in crypto or crypto standards or rules for crypto standards. Maybe you can elucidate me and provide links to Putin(istas) engaging in any not insigificant way in crypto standards, particularly in making sure there is "wiggle room".

We've been through this before. Standard wars, HTML5 proprietary attributes, OOXML, etc., etc. which essentially beg to deconstruct the very idea of proposing a "standard" in the first place.

And as you seem to be interested in LGBT matters, Belgium's previous prime minister was gay. So that should not be a problem.

Gay ≠ transgender and in fact

  1. Gay MtF transgender = lesbian, but are generally shunned by them.
  2. Straight MtF transgender are shunned by gay male culture.
  3. Gay FtM transgender tend to be shunned by "cis-" gay men.
  4. Straight FtM transgender are shunned by straight women.

In general: a lot of LGB-friendly T-haters out there, where we actually have to specify that T ≠ testosterone....

@3/4 * the lulz

Which is why some of us would like to have the mostly non-existent ability to encrypt our private data on our own computers or protect it from disclosure on the internet via malicious software.

ModeratorMarch 28, 2017 8:27 PM

Please save discussion of LGBT matters for another forum, it's way off-topic here.

ThothMarch 28, 2017 8:30 PM

@all

What actually matters is the market and industry's perspective.

Ukraine, just like Russia, China, Japan and South Korea can roll out as many crypto algorithms as they want but the fact is chip fabbing companies and organisations will not bother to go the extra mile of doing "custom algorithm" accelerators and the such.

When the market has very low demands for an algorithm (not from open source and individual perspective but international standards perspective), nobody's going the extra mile to do "custom algorithm" unless it's lucrative enough.

One good example in the hardware accelerator market and hardware encryption market I have noticed is despite the above countries having custom algorithms, the hardware encryption and accelerator sales wouldn't be all too bothered to supply those custom algorithms as these nations will conform automatically to the standard NSA's favourite - AES and NIST based ECC.

Why do we look from hardware accelerator and crypto chip perspective is because of the use of hardware security and acceleration that drives the uptake of an algorithm from very powerful sectors (business, finance, governments ...) as nobody would want slow crypto (which is why NSA used this to target the AES competition) and hardware acceleration is preferable. Also, governing standards for security compliance in the business, finance and government sectors would usually agree on internationally recognized algorithms like AES and ECC which gives more security appliance choices when it comes to hardware security (i.e. HSM and Smart Cards) perspective that are mandated in these practical real world application and real world compliance standards. The reason 3DES is still strong is because the PCI-DSS, NIST et. al. have not yet pushed them out and the chip makers simply continue to produce chips with 3DES acceleration (i.e. HSMs and Smart Cards) and this turns into the vicious cycle of algorithms having a prolonged lifespan beyond it's shelf life.

From the security market perspective, custom algorithms are like extinct dinosaurs or would-be extinct dinosaurs.

Governments and organisations will sooner or later comply to the norm of NSA selected algorithms because of practicality, market pressure and availability, international standardizations and compliance from governing bodies of different industries (i.e. PCI-DSS, FIPS 140 et. al.).

National ciphers are simply just some academic exercise that's only that useful as they will have to bow to the above pressure and standards mentioned and there is no escaping from such reality.

ab praeceptisMarch 28, 2017 8:39 PM

My Info

We've been through this before. Standard wars, HTML5 proprietary attributes, OOXML, etc., etc.

But that wasn't the context. This here was about standards in the crypto community. There are, in fact, other and more bureaucratic standards such as nist or pci but about those one may care or not (bankers probably will, security people probably less).

As for Putin(istas) I am presumably to take your ignorance of my request to provide any evidence for your weird assertions as proof that you have none and just felt like ranting ...

provide links to Putin(istas) engaging in any not insigificant way in crypto standards, particularly in making sure there is "wiggle room".

Gay ≠ transgender and in fact etc. blabla - that may be of interest elsewhere.

[ts] but are generally shunned by them.

I let you in on a little secret: Maybe they are shunned because they are annoying everyone with their obtrusive and persistant wanton inventing of non existing arbitrary relationship between any and everything and ts specific stuff?

So, again: I'm in no way against you and I wish you a happy life but stop already to molest us with your very personal and utterly subjective "worries" that are nothing to do with crypto or security.

ab praeceptisMarch 28, 2017 8:51 PM

Thoth

While you are right and I agree I feel it should be mentioned that crypto accel. a) usually doesn't work like most think and b) isn't that essential anymore for most use cases (due to even smartphone cpus being powerful enough) and c) can also be achieved by other means, e.g. scaling (cavium tiles, gpu et al.).

With the exception of intel and aes usually crypto accel. doesn't work by offering "xyz encrypt/decrypt string abc" but rather by offering algorithms (often called "crypto primitives") that are typically used and for many algorithms. Montgomery ladders are an example.

Also keep in mind that bigger players like quite some countries *can* develop and produce accel. hw. and almost certainly do

But again, I generally agree with your observation (to put it slightly differently) that big corps. influence and define crypto way too much.

ThothMarch 28, 2017 9:35 PM

@ab praeceptis

"due to even smartphone cpus being powerful enough"

The reason is there are optimized instructions that detects AES-like structures these days or at the very least, these crypto-like structures have been made much much more efficient.

Also, most mobile chipset with ARM has the latest ARM instruction for crypto acceleration that includes AES, RSA and ECC. If you are writing a C library (yes I know you hate C but C is everywhere) for crypto, you can simply call the ARM instruction and then accelerate even faster.

They do offer an entire round of AES, single round of AES and such. Linked below is the ARMv8 manual. Scroll to page 99 for instruction set. I have included the ARM instructions below from that page to make it easier.

PMULL Vd.1Q, Vn.1D, Vm.1D
Polynomial multiply long (vector): AES-GCM acceleration 64x64 to 128-bit.
PMULL2 Vd.1Q, Vn.2D, Vm.2D
Polynomial multiply long (vector, second part). Upper lanes AES-GCM acceleration 64x64 to 128-bit.
AESE Vd.16B, Vn.16B
AES single round encryption.
AESD Vd.16B, Vn.16B
AES single round decryption.
AESMC Vd.16B, Vn.16B
AES mix columns.
AESIMC Vd.16B, Vn.16B
AES inverse mix columns.
SHA256H Qd, Qn, Vm.4S
SHA256 hash update accelerator.
SHA256H2 Qd, Qn, Vm.4S
SHA256 hash update accelerator, upper part.
SHA256SU0 Vd.4S, Vn.4S
SHA256 schedule update accelerator, first part
SHA256SU1 Vd.4S, Vn.4S, Vm.4S
SHA256 schedule update accelerator, second part
SHA1C Qd, Sn, Vm.4S
SHA1 hash update accelerator (choose).
SHA1P Qd, Sn, Vm.4S
SHA1 hash update accelerator (parity).
SHA1M Qd, Sn, Vm.4S
SHA1 hash update accelerator (majority).
SHA1H Sd, Sn
SHA1 hash update accelerator (rotate left by 30).
SHA1SU0 Vd.4S, Vn.4S, Vm.4S
SHA1 schedule update accelerator, first part
SHA1SU1 Vd.4S, Vn.4S
SHA1 schedule update accelerator, second part

Big countries do produce their own accelerators and this have been the niche market case. Samsung produces crypto chips with it's SEED algorithms (I own a few Samsung Smart Cards specifically with Korean SEED algorithm (S3FS91J type Samsung smart card chip). In fact, I am holding a batch of the S3FS91J type smart card chip which are known to be out of production already.

If you look at the other most recent smart card chips Samsung produces, they don't even have Korean SEED algorithms and instead stuck to NIST FIPS 140. Linked below is their catalog sales page.

That leaves with Japan's Camellia cipher, Russian GOST and Chinese SM algorithms. So far, only the Korean SEED algorithm made it to known standards like the JavaCard API and none of the other national standards made it.

I have seen Chinese made crypto accelerators and smart card chips with Chinese SM algorithm and that's the exception besides the Samsung's now EOL-ed Korean SEED capable chips.

Besides the Chinese and Koreans with their national algorithms manufacture in limited amount on their smart card chips and crypto accelerators (in limited quantities), I have yet to seen someone do a full production GOST and Camellia cipher accelerator. Maybe I am missing out on these accelerator chips but I do be interested to get a few of them to add to my small collection of crypto chips and smart cards I have hoarded.

Those have inevitably pretty much gone the way of the dinosaurs in a rather silent manner.

The trend is that most chip fabs realized that nobody's using SEED, Cameilla, GOST and SM algorithms and the fact that Samsung has dropped the production of SEED capable smart card chips shows the market is actually pretty centralized around NIST algorithms and it's very limited and not lucrative business.

Even the Chinese chip makers only offer their SM capable chips when requested otherwise it simply makes non sense to provide chip with Chinese SM algorithms when 99% of customer base don't need Chinese algorithms and prefer NIST algorithms.

If you still remembered my ordeals I went through to make ChaCha20 work on an Infineon JavaCard smart card, it is a lot of effort getting them to work properly because you have no control over the Infineon instruction sets and have to rely on whatever high level Java API they gave you and hope the JVM inside is efficient enough to get the job done. Although, I should be a little reserved for the fact I have not tested a 32-bit version on smart cards supporting full 32-bit Integer instructions which may have a chance of making it a little faster but not any faster than HW setup.

Imagine if a nation decides to implement a national algorithm, they will hit the same ceiling as I have experience under the circumstances they do not want to produce their own chips with HW instructions baked right into the chip. They have to ask the major chip makers for APIs and that's what you get when you have no control over the chip's HW structure.

In the end, there's just too much economic and practicality issues at hand for nation states to stray off the beaten path and then realize that it's just not the best way to go.

Link:
- https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf
- http://www.samsung.com/semiconductor/products/security-solution/smart-card/

AnonMarch 28, 2017 9:53 PM

It doesn't matter who invented an algorithm as much as whether the algorithm is secure, and what the motivations are for its creation.

e.g. DUAL_EC_PRNG apparently has the motivation of NOBUS at its core regarding breaking it.

If hardware makes crypto faster, surely this then reduces one of the desired properties of crypto, namely that it is slow, requiring huge investment in compute power?

I'm still not convinced by some of the arguments of "quantum computing". Sure, it can drastically reduce compute times in specific areas, but so far it hasn't delivered the theoretical breaks that were anticipated. A question that doesn't seem to be addressed adequately is:

1) why hasn't it happened yet,
2) can it happen, and;
3) if the answer to (2) is yes, when do we think it will happen given (1)?

ab praeceptisMarch 28, 2017 10:00 PM

Thoth

That's certainly all true and I regret as much as you do that large corps (because that's pretty much what's behind it) plus the washington agencies basically dictate what are the crpyto standards, i.e. which ones are to be supported. *Of course* those are what chip designers target foremost.

That said, there are increasingly many countries who care little about that diktat and implement their own standards. Look, for example at Russia. Certainly enough, all the digital systems in the weapons systems and other things must conform to their own GOST standards.

On the other side there are certain basic constructs that are used everywhere, e.g. Sponges, Feistel, and others, so a russian chip with crypto accel most probably does *not* do complete GOST algos but rather crypto primitives, hence it can, at least in many cases, as well be used for non-russian algos.

Btw. one should give too much on designations used by manufacturers. From what I see at first glance in the arm list you mentioned, those are mostly crypto primitives. It's just normal for manufacturers to name them for the *typical* algorithm that also happens to be what most customers look for.

And btw, yes I do remember your struggle with javacard and not getting at the chips.

What I meant with smartphone cpus was simply that those are powerful enough - without hw accel - to run pretty much all crypto algos, at least at the rate most users need. To Joe and Jane it doesn't mean a lot whether, say PK session establishment (PKE, etc) needs sub-millisecond or hundredths of a second.

To close with a funny remark: Keep in mind that we today sometimes try hard to make some algos *slow*, e.g. passphrase hashing ratchets like Argon, etc. *g

DaveMarch 28, 2017 10:32 PM

@Howard: "As it happens Apple removed 3DES as a default cipher in watchOS 3.1.3* but in iOS 10.3** they added it to their SCEP client (DES was deprecated); it's still extremely popular in the credit card world though".

Ouch, I didn't know they were still using single DES in SCEP. 3DES is fine, but given that it's only present for historical reasons they would have been better off just going to AES. Perhaps in another 20 years...

Martian MichaelMarch 29, 2017 1:51 AM

Everybody agrees that you should not invent your own cipher.

However, if you don't trust the standard US, Russian or Chinese cipher, why not use all three at the same time. Sure it is significantly slower than the optimal, but if just one of those are safe, then your secrets are safe.

WinterMarch 29, 2017 1:58 AM

"However, if you don't trust the standard US, Russian or Chinese cipher, why not use all three at the same time."

Inventing a national cypher also develops internal know-how about cryptography. Just like you need your own labs to understand the science literature, you need people who design and break cryptographic systems to understand the standards.

This is one way to do that.

WillMarch 29, 2017 1:59 AM

So what is Kalyna to be used for?

Are Ukrainian businesses or institutions enforced to support it, or use it exclusively, by law?

Has there been any uptake?

And the Wikipedia link says it was selected in 2015; was the whole contest started before the revolution in 2014, or?

So many questions ;)

MaestroMarch 29, 2017 4:08 AM

@ Dirk Praet

'In an art context, that would be painters from the Flemish Primitives over Rubens'

appreciate everything you have to contribute here, Dirk, I'm a fan
without continuing this topic beyond this message, I will just add the brilliant Belgian actor Mattias Schoenarts to your list. He's been compared to Marlon Brando and its not a stretch. Check out 'Rust and Bone if you haven't - and for gods sake don't read the bio before you see it

RomanMarch 29, 2017 4:43 AM

@Will

Ukrainian cryptographic competition was held in 2007-2010, and Kalyna was selected among other candidates. After further researches it was adopted as the national standard in 2015 (governmental direction was issued in December, 2014, so the standard is dated 2014).

Kalyna is used to replace GOST 28147-89 in developing cryptographic systems. Mainly, it is oriented to governmental sector, where Ukrainian laws guarantee information protection (like databases of State Fiscal Service). In these fields Kalyna application is obligatory.
If local businesses do not deal with such information, they can choose any crypto they want. AES, ECC, etc. is also widely spread in Ukraine, but many local developers prefer to include Kalyna and other crypto DSTU's in their libraries for efficience and compatibility.

ThothMarch 29, 2017 6:26 AM

@Dave

Most of the security for banks (i.e. ATMs, credit cards, debit cards, payment terminals) uses 3DES. The Card to Terminal communication are usually done with 2 Key type of 3DES. That will give you security of less than 80 bits to crack the comms between card and terminal. Terminal to backend financial system are usually 3DES 3 Key but who knows it might be just 2 Key as well :) .

Financial systems are sitting ducks waiting to be plundered. They are too busy with no downtime and security is secondary.

Dirk PraetMarch 29, 2017 6:33 AM

OT

@ Maestro

I will just add the brilliant Belgian actor Mattias Schoenarts to your list.

Both Matthias Schoenaerts and Luc Tuymans are regulars at some of the bars I hang out in my home town. I actually know Luc, his wife Carla Arocha (a talented Venezuelan artist) and their entourage quite well as I used to date one of his assistants. He's quite a bit of character, and despite his somewhat grumpy demeanour towards folks he doesn't know (or like) an incredibly warm, loving and generous person who reminds me a lot of my late grandpa.

I'm not too big of a fan of Schoenaerts as he's being typecasted too much and because he always gets all the girls. His dad Julien Schoenaerts was an almost mythical actor whose rather unconventional lifestyle and eccentric personality to date remain the stuff many an urban legend here is made of.

ThothMarch 29, 2017 6:52 AM

@Roman

This will pose a problem to Smart Cards since this means Ukraine must roll their own cards for Government use and this is not easy as it's expensive to add features to Smart Cards and pose compatibility issues with current international standards for Smart Cards with Ukraine's own cipher.

Kostadin KostadinovMarch 29, 2017 7:52 AM

For cripto algorithm it is crucial to be public for at least 5 (and more) years and NO successful cracks was filed.
Does anyone know how long it is public?
If it is brand new a risk mitigation approach could be to announce cracking competition with prizes.

RomanMarch 29, 2017 9:21 AM

@Thoth

Crypto on smart cards and USB-tokens can also be implementented in software (for a card/token controller), and a very few applications cannot work without hardware acceleration for smart cards. All Ukrainian crypto standards are already implemented and used on USB-tokens (an example of a massively produced token, description in Ukrainian: http://iit.com.ua/index.php?page=itemdetails>ype=1&type=1&id=50 ; the updated version of it with the newest standards is being certified). The heaviest protocol implementation for practical applications run quite fast, being completely comfortable for users.

My InfoMarch 29, 2017 9:57 AM

@Kostadin Kostadinov

For cripto algorithm it is crucial to be public for at least 5 (and more) years and NO successful cracks was filed.
Does anyone know how long it is public?
If it is brand new a risk mitigation approach could be to announce cracking competition with prizes.

This is too simplistic. The problem does not reduce to a certain number of years with a certain prize unclaimed.

A mathematical reduction to a well-studied mathematical problem with no successful cracks is better. For example, RSA is mathematically reducible to the well-known problem of factoring the product of two large primes. It is mathematically impossible to crack RSA without a general method to factor a large composite (semi-prime) number in reasonable time.

The block crypto paradigm is not reducible to any known mathematical problem that has been well studied over many, many years (>>5) without finding an effective solution.

I would like to clarify some of my above remarks. I am not knocking Daniel J. Bernstein's crypto. I am knocking its lack of independent peer review. We simply need more researchers to read Elliptic Curves for Dummies or whatever background they need to catch up, and go through and verify the mathematics behind these algorithms. I am at a loss to explain why this does not seem to be happening from independent quarters.

This leads us to yet another Millenium prize problem, in case we ever get bored with P vs. NP.

My InfoMarch 29, 2017 10:10 AM

@Thoth

Financial systems are sitting ducks waiting to be plundered.

Sitting ducks ???

ThothMarch 29, 2017 11:48 AM

@Roman

I don't understand that webpage. Is there an English Common Criteria Security Policy and Target Eval paper that I can read ?

@My Info

Yes. Banking systems are still full of holes. I can't be too specific due to contractual agreements with some of them but if you have served them, the ugly side starts to show pretty quickly.

ThothMarch 29, 2017 12:06 PM

@Roman

I noticed a reference to: ГОСТ 28147:2009 which Google Translate points to GOST 28147:2009. Not sure what's that anyway until there's an English page referencing the USB CCID device to Kalyna to assert it's identity.

Is the supposed implementation of Kalyna done on the IC chip as a specialized mask on the IC's circuitry or is it done on a JavaCard level extending the Cipher class (or something similar in MULTOS) or is it on the IC chip's firmware level ?

Would be interesting if it's either firmware or JavaCard/MULTOS level implementation.

My InfoMarch 29, 2017 2:11 PM

Re: @Thoth

Yes. Banking systems are still full of holes. I can't be too specific due to contractual agreements with some of them but if you have served them, the ugly side starts to show pretty quickly.

There is definitely something really, really ugly going on with these banks.

There was a lot of resistance in the U.S. to the introduction of chips in bank cards, and that was apparently overcome by explaining to consumers that they were already fashionable in Europe. The magnetic stripes still work for the most part, although I suppose one could obliterate the magnetic stripe on a bank card and leave the chip functional for extra security.

I was at a locksmith shop in Baltimore, Maryland, and I was curious about a credit-card operated safe that was for sale. Then the proprietor showed me a refrigerator magnet about the same size and shape as a credit card. I started to get curious about what that would do to the magnetic reader in an ATM or retail POS terminal — obviously I never tried it, though.

The chip readers present a similar vulnerability. Making electrical contact with an unknown device introduced by a consumer theoretically subjects the entire ATM or chip or card reader machine to destruction by an electric pulse, if as usual there is no additional protection. Suppose someone had a Taser-type device the same size and shape with the same profile of electrical contacts as an ATM card.

A certain percentage of credit and debit card sales is deliberately allocated to unprosecuted fraud. (The kind where you call customer service, they usually refund the money after some discussion, but they don't consider it worthwhile to go after the thieves.) There was a great deal of resistance from the thieves in law to the introduction of chips in bank cards, until they had learned to effectively steal from the chips, as well.

There is a racket going on here, where the banks are being deliberately slack in their security in exchange for a certain measure of restraint on part of the thieves in law who continue to skim off the banks. A gentlemen's agreement, in other words.

AnuraMarch 29, 2017 2:33 PM

@My Info

There was a lot of resistance in the U.S. to the introduction of chips in bank cards, and that was apparently overcome by explaining to consumers that they were already fashionable in Europe.

I'm not sure you can say it was overcome. We only implemented the chip, not the pin. So even when we adopt a new standard, we deliberately choose a less secure one. But it looks like we are trying, and in the end, isn't that what really matters?

ab praeceptisMarch 29, 2017 4:02 PM

Thoth

You can think of Gost as the "russian nist".

The old (and still used and standing strong) blockcipher was des-like while the new one, from the top of my head, is more aes-like. But careful, I might be wrong.

As for that ukrainian thing, it's most probably yet another incarnation of the ukrainian "we must do everything different from Russia", i.e. non-Gost in crypto.

From my pov kalyna (and other ukrainian crypto) simply isn't worth a closer look (e.g. because that market is insignificant unless one happens to deal in second hand potatoes); similarly a belgian or a german crypto standard doesn't mean a lot outside those countries.

About the only crypto standards outside us of a are probably eu, japanese, chinese, russian.

Btw. some Gost ciphers actually are in diverse crypto libraries/products. Most people just don't notice them and they never heard of it.

Dirk PraetMarch 29, 2017 4:51 PM

@ ab praeceptis

Btw. some Gost ciphers actually are in diverse crypto libraries/products. Most people just don't notice them and they never heard of it.

You need to check out Gostcrypt. It's a fork of Truecrypt, but with all GOST ciphers and algorithms. Latest version also contains the Russian GOST Kuznyechik (grasshopper) standard. Totally recommended on your laptop if you want to spend a couple of hours trolling some really inquisitive US CBP folks.

Nick PMarch 29, 2017 5:04 PM

@ Dirk Praet

"Totally recommended on your laptop if you want to spend a couple of hours trolling some really inquisitive US CBP folks."

That's great lol. The trick would probably also work with any common program you know the commands to but with language localized to Russian or Chinese. Tell them the truth: you just think the letters in other alphabets are beautiful and refreshingly different. I'd skip Arabic since they go all out on that.

ab praeceptisMarch 29, 2017 5:13 PM

Dirk Praet

Good tip, thank you. But I have been playing with the grasshopper (e.g. Ada and Haxe bindings) since quite a while already (also, of course, with the old des like cipher).

I'm, btw. not so sure that Gost ciphers are a good way to annoy us of a agencies. After all Russia has been one of their major target since many, many years and hence, so I presume, Gost ciphers are well known and studied ones in those circles.

In case it's of interest to anyone my preferred way to throw them off is to (very sensibly and carefully) adding stages or variators to well proven algorithms, which comes somewhat natural in my case as I usually deal with limited and well defined user group scenarios. I also mention that as it seems to serve well as an emergency barrier for a pq scenario.

That said, I *strongly* suggest anyone thinking along that path to meticulously design and specify and test any constructs to make absolutely sure (verifiably, please) that the complete "ratchet" is not weaker in any regard than the basic elements.

To put it funnily: Do *not* use the Collatz function for 2nd stage PKE variation (but rather maybe a grasshopper)*g

ThothMarch 29, 2017 7:02 PM

@ab praeceptis

The only crypto standards with huge major impacts is the USA.

Japan's Cameilla is still stuck in Japan and not popular. No major HW implementation. Korean SEED was the only one successful enough to make it to HW implementation and even international standard APIs like JavaCard. JC 2.x.x and the latest JavaCard standard which is JC 3.0.5 have SEED in it. Too bad Samsung discontinued production of SEED capable Smart Cards. I have a few of those in my personal collection as collectable.

China's SM algos are still actively produced by Chinese fab but they are not introduced globally and this is possibly the fate of Ukraine's Kalyna if they put them on HW. Russia Grasshopper is something I am not familiar. Never seen any HW for that on Smart Cards or known HSMs before.

The HW with Chinese SM algorithm shouldn't be all too hard to obtain and add to my personal collection.

Indeed most of these less known ciphers and their HW implementations are not easy to find but may exist.

Whoever implementing new ciphers for national standards should really consider those of Twofish and Serpent which are known to be stronger than Rijndael.

mooMarch 29, 2017 8:53 PM

Only vaguely related, but while looking for info on block ciphers I came across this amusing story by Thomas Ptacek:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

If your crypto code is written by non-experts, it is _very likely_ to suffer from several of the weaknesses mentioned in this story and probably a bunch of other ones too. Writing secure crypto code is seriously hard, even for experts. Non-experts will produce vulnerable software and not even know it.

My InfoMarch 29, 2017 10:02 PM

Re: my own previous comment March 28, 2017 1:39 PM

https://www.schneier.com/blog/archives/2017/03/kalyna_block_ci.html#c6749191

I don't know what it is called, but this is a known method of cryptanalysis, alongside linear and differential. Now that I have posted about it I recall a few more details.

The bits represented by logit values are subject to a great number of constraints, basically from the truth tables of all the elementary logic gates in the algorithm. In this method of cryptanalysis, a so-called loss function is assessed at each step against the complete array of logit values.

The loss function has to be so severe that, essentially, the entire solution is disqualified if a single elementary logic constraint is not satisfied. Then partial derivatives of the loss function with respect to each logit value are computed numerically, and some method of steepest descent is applied to minimize the total loss. With the randomized or quantum methods it is hoped that one may avoid or step over any local minima in search of a global mininum for the loss function.

The severity of the loss function led to its being named after the Code of Hammurabi, for the severe punishments imposed by the Code for even minor infraction.

It seems to me that a variant of this method of cryptanalysis is automated and actually used in modern-day cell phones and such for error correction.

Does anyone have more information on this method of cryptanalysis?

My InfoMarch 29, 2017 10:21 PM

@moo

Writing secure crypto code is seriously hard, even for experts. Non-experts will produce vulnerable software and not even know it.

They [the non-experts] can and they do all the time, and that's what we're stuck with on our computers. The entire O/S and software application stack has to be secure, not just the crypto code, and the crypto experts are not about to write all that code for us, even though all of it is equally security-critical.

Excuse me. The rock-star brogrammer attitude simply is not producing effectively secure code for us, any more than the blonde bimbo math-is-hard attitude. If you think about it, both attitudes are one and the same, and neither one is helpful for writing secure code.

The right way is to improve the expertise of the non-experts who are writing the code, and to educate, enable, and empower them to write more secure code. There is just too much code, i.e. too much complicated stuff that we expect our computers to do, and do correctly.

John GaltMarch 29, 2017 10:31 PM

@ My Info

[[[ The right way is to improve the expertise of the non-experts who are writing the code, and to educate, enable, and empower them to write more secure code. There is just too much code, i.e. too much complicated stuff that we expect our computers to do, and do correctly. ]]]

You must be talking about the educated idiots who are developing systemd.

faMarch 30, 2017 7:33 AM

OT

@Dirk Praet:

Both Matthias Schoenaerts and Luc Tuymans are regulars at some of the bars I hang out in my home town.

Witzli-Poetzli ??

Dirk PraetMarch 30, 2017 9:22 AM

@ fa

Witzli-Poetzli ?

8-) Charming place, really cool owners, but a bit too small for me. The sidewalk part close to the cathedral is kinda nice in summer.

My InfoMarch 30, 2017 10:20 AM

@John Galt

You must be talking about the educated idiots who are developing systemd.

You are absolutely right! The systemd rock stars! The ones who bypassed simplicity and correctness in favor of obscurity and all kinds of bizarre hooks in the start-up code! No one but an "expert" can touch systemd or even debug it!

And the lower lips jutting out like little boys whose dog ate their homework!

RobMarch 30, 2017 11:46 AM

I was always suspicious of AES since the snowden leaks. A lot of people including Bruce seemed to feel comforted by the information that NSA cannot break AES. I was never so sure. I think it is a mistake to assume what the NSA can or cannot do. Just because they are spending a lot of time and effort in other means of accessing communications doesn't mean that they have zero options when it comes to cracking encrypted content.

And to the comment that we like AES because it is not from the US... that it is Belgian... seems a little weak. Yes... a number of cryptographers from around the world did devise the algorithms... but a lot of the selection process was overseen by the NSA. Why would we view this as clean from US influence?

Even now with the CIA leaks... people are immediately saying... seeeee! public encryption algorithms are save and we are so sure of it because the leaks show that they are using other ways to read data. What if it takes 30 times as long to crack encrypted content... and easier/faster ways are valued? And if they do have ways to crack public algorithms... why would those documents be at the same classification level as many of these other docs? If they did... I would imagine a fairly small team being aware of it at all... and on documents that never leave rooms in the basements of these organizations.

RobMarch 30, 2017 11:54 AM

Also.. if these leaks are considered comprehensive views into US govt capabilities... how come there has yet to be a leak of non-public NSA algorithms? We haven't seen any... which means that yes.. there are levels of secrecy that have not been compromised. Wouldn't the the capability to crack RSA/Elliptic Curve/AES... be classified to the same or higher level as implementation details of non-public NSA algorithms?

I just really feel skeptical at viewing the leaks as somehow confirming that public encryption algorithms are like... totally safe!

Clive RobinsonMarch 30, 2017 12:31 PM

@ Rob,

A lot of people including Bruce seemed to feel comforted by the information that NSA cannot break AES.

By and large they don't want to, it would be way to much effort. As I indicated above without a lot of care a practical implementation will hemorrhage information via timing based side channels (which the AES competition very much encoraged). It's why I advise "Off-line" usage and only move the "at rest" ciphertext to an online system for communications.

From a resource point of view as long as attacking the system is easier than attacking the algorithm, that's what the NSA will do. However there are occasional supprises such as that of common use of values in Diffe-Hellman that enabled precomputation that gave rise to the "logjam" attack.

There are other attacks that become efficient with bulk collection, that would be to expensive with targetted attacks. For instance factoring out primes from RSA is in effect prohibitive, however checking the pq multiple against other pq multiples for a common prime has a low cost algorithm. Not a lot of use at first glance. But what about embbeded systems which startup with little or no entropy then create the p and q primes for the PubKey Cert. There is a much much higher probability of there being common primes in their certificates, which opens up the potential for a bulk attack. Thus the effort to factor just one pair enables a rapid attack on other PubKey Certs from the same equipment type...

ab praeceptisMarch 30, 2017 4:18 PM

Clive Robinson, Rob

Clive pretty much nailed it down. With more than 99.9% of all systems used basically being crap collections, why should nsa, or for that matter any other criminal gang, attack crypto?

But I suspect that there are more dangers and really ugly ones. Most people looking at cryptography look from a more or less mathematical angle - plus loads and loads of "religious" credo blabla like "obscurity is not security" plus common human assumptions like "more is always better".

For a start: Every state had observation/eavesdropping capabilities built in any technology that even remotely allowed confidential communication or transport of information. That didn't start with postal riders and it didn't end with fbi desiring to have readily available listening in and code breaking capabilities in every device (-> clipper) and in every major node of communication networks.

Short: It can be considered as certain that states, will do pretty everything to be able to listen in and to deny everyone the capability to communicate confidentially.

Next, and less frequently seen and considered issue: How do politicians tick? Do they use military means and ways to act when they fight each other, other countries, and citizens? No. They use means and ways of secret services, and, importantly, they tick like that.

Which directly leads to tactics like creating and/or shaping "truth" and, if any possible, reality. That is exactly what we observe - and they have the means to do so, beginning with kindergarden and school. A very major part of what and how we feel, think, believe, act as adults is largely shaped by the state or state controlled mechanisms and institutions.

Well noted, I'm not into conspiracy theories but when we talk about security we must not exclude any vectors. In particular, we must not allow the set of potential dangers, threads, attacks we consider to be limited by any third party such as the state.
Plain english version: Just ask any of the many citizens who believed that laws are fair and just and for the best of all and that state agencies would a) understand/interpret the laws the same ways the citizens did and b) act lawfully.

Let's play a game. Assume you were a king who liked to stay on his comfortable throne. I'll keep that very short because there is loads of reading material about that; Let's just accept the premise that carefully observing the higher people at court wouldn't be enough and that you would (justifiably, from your perspective) feel the need to be able to observe/listen to anything and everything, to any and every communication in your country.
You would soon arrive at the point where you see that there can always be crypto that your secret service can not crack. Today, for instance, they could crack des but aes is already available and soon there might be quadfish-512 which would be impenetrable to your secret service.
You would want all the keys. Simple as that. Because, no matter how hard any (sym.) crypto, you could decrypt everything if only you had the keys.
Obviously, though, your citizens would fight hard against you having all keys. So you need a scheme to get at all their keys with them even being happy. Enter PK.

Again, this is not about conspiracy theories and I'm not saying that it *is* like that. But we have to at least look at it and either reasonably and soundly exclude that possibility or else we have to accept it as a member of our threat set.

Let's check the hypothesis - well noted from the angle of powers that be ticking secret service like.

For a start, there are many crappy implementations out there (-> openssl, which for decades was pretty much the only game in library town and omnipresent).
Moreover the only two widely used PK algorithm types have quite some parts in common (I hate it when my poor english forces me to put things lousily. Apologies. Kindly try to follow me anyway). -> quantum computers pretty much breaking both rsa and ecc.
As if that wasn't bad enough, we do not even use *real* primes but rather "probable primes". Et voila, researchers are able to tell from some used "primes" what ssl library we use. So much for random moduli ...
Funnily, we *could* work with real primes and even at acceptable cost - but we don't. For whatever strange reason we seem to be happy to work with crappy "probably-primes" and, to make it worse, with strongly biased algorithms.

If I were that king (from above) I'd be a smiling happy man. Why? Because I would have succeeded to drive my citizens to happily hand over all the sym. keys used right when they are chosen/created.
Quadfish-512? Great, go ahead - as long as your crappy PK mechanism implemented in crappy libraries and on crappy OSs hands me the keys used I will gladly allow the "use 512 bits sym crypto!" dance.

More InformationMarch 30, 2017 6:04 PM

A little note for non-native English speakers: "assess" is a synonym for "evaluate," and whereas most mathematical functions are evaluated, a "loss function" is "assessed." Even the preposition changes: a mathematical function is usually evaluated "at" (or less formally "for") some particular point in its domain, but it seems most natural to say that a loss function is assessed "against" or "at" (but never "for") a particular point in its domain.

* * * * * * * * * * * * *

Another idea I had on that was a slight change of paradigm for the block cipher:

Whereas the operation C=Ek(P) is easily reversible P=Dk(C) for any fixed key k, suppose instead that the plaintext P is considered fixed, and whereas in this case it is easy to compute the ciphertext C from the key k, it is not intended to be so easy the other way around.

This does not seem to be a natural situation, and what I would want to do is to attempt to embed this computation of the ciphertext C from the key k, (given a fixed plaintext P,) in a fully reversible computation with Toffoli gates.

In this embedding I would want to find as many internal logical redundancies (or even, in a more general sense, probabilistic correlations) as I could in order to minimize the number of extra inputs and waste outputs for the reversible circuit that computes the ciphertext C from the key k, given a fixed plaintext P. Without being able to guess or correlate or tie down the values of those waste outputs, it would be very difficult to effectively reverse the computation to discover the key k from the ciphertext C.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.