Skein News

Skein is one of the 14 SHA-3 candidates chosen by NIST to advance to the second round. As part of the process, NIST allowed the algorithm designers to implement small "tweaks" to their algorithms. We've tweaked the rotation constants of Skein. This change does not affect Skein's performance in any way.

The revised Skein paper contains the new rotation constants, as well as information about how we chose them and why we changed them, the results of some new cryptanalysis, plus new IVs and test vectors. Revised source code is here.

The latest information on Skein is always here.

Tweaks were due today, September 15. Now the SHA-3 process moves into the second round. According to NIST's timeline, they'll choose a set of final round candidate algorithms in 2010, and then a single hash algorithm in 2012. Between now and then, it's up to all of us to evaluate the algorithms and let NIST know what we want. Cryptanalysis is important, of course, but so is performance.

Here's my 2008 essay on SHA-3. The second-round algorithms are: BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein. You can find details on all of them, as well as the current state of their cryptanalysis, here.

In other news, we're making Skein shirts available to the public. Those of you who attended the First Hash Function Candidate Conference in Leuven, Belgium, earlier this year might have noticed the stylish black Skein polo shirts worn by the Skein team. Anyone who wants one is welcome to buy it, at cost. Details (with photos) are here. All orders must be received before 1 October, and then we'll have all the shirts made in one batch.

Posted on September 15, 2009 at 6:10 AM • 27 Comments

Comments

curiousSeptember 15, 2009 6:43 AM

I've always wondered, what's in it for the winning algorithm? Is it just the honour? Or will NIST purchase a ''license'' in some form?

Bruce SchneierSeptember 15, 2009 6:53 AM

"I've always wondered, what's in it for the winning algorithm?"

Fame and glory, nothing more.

Every group that submitted had to explicitly sign away any rights to both the algorithm and the software implementations.

StevenSeptember 15, 2009 8:27 AM

A recent study (http://eprint.iacr.org/2009/438) attacks Skein up to 35 rounds out of 72. Would you please give comments on it? Thanks!

Bruce SchneierSeptember 15, 2009 8:37 AM

"A recent study (http://eprint.iacr.org/2009/438) attacks Skein up to 35 rounds out of 72. Would you please give comments on it? Thanks!"

It's a really good paper, with a whole series of attacks against reduced-round Threefish.

The particular result you mention is a "known-related-key boomerang distinguisher." The complexity of the attack against Threefish-512 is 2^478, making it slightly better than brute force but still completely impractical forever. (The attack is 2^83 more complex than it is against 34 rounds, which gives you some idea of how the difficulty of attacking Threefish increases with the number of rounds.) While it's certainly possible that this attack might be pushed a few rounds with some new and clever cryptanalysis, there's no way in the world it'll ever get anywhere near 72 rounds. The paper says: "our results conclude that at least 36 rounds of Threefish seem required for optimal security guarantees."

We talk more about the paper in Section 9.5 of the Skein document.

NotSoAnonymousWhenOnlineSeptember 15, 2009 9:02 AM

"Blue Midnight Wish".
Is there a secret to coming up with these names? Something that makes the quoted not be sorta ridiculous? I mean, no one will ever say they used Blue Midnight Wish for anything, and calling it BMW doesn't seem to really do the trick either... At least "Blowfish" has a good ring to it....

VincentSeptember 15, 2009 9:07 AM

Revision files still not posted to skein-hash.info, 404s all around. Reading your local copy here.

gregSeptember 15, 2009 10:50 AM

A quick google doesn't give much info on cipher modes with tweakable block ciphers. Does anyone know if theres been much work in that direction?

SanjayaSeptember 15, 2009 12:48 PM

Bruce, you should know that this page won't load on Firefox - it just gives an error, "The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.", and will not load the page at all, let alone allowing me to read or post comments.

gSeptember 15, 2009 3:18 PM

The winning algorithm will presumably be known as SHA-3, and its name during the contest will fade away. AES was formerly known as Rijndael; at least Blue Midnight Wish is easier to pronounce.

Daniel WijkSeptember 16, 2009 2:32 AM

nice_dude3: I think Schneiers submissions in past competitions like this and his experience working in the field of cryptology more than makes up for not having a career in the university world.

With that said I actually dont know if Schneier has a Ph.D or not :-)

Clive RobinsonSeptember 16, 2009 9:05 AM

@ Daniel Wijk,

"With that said I actually dont know if Schneier has a Ph.D or not :-)"

It does not mater, I have posted about this in the past.

A Ph.D is not like a "taught" degree (BSc, MSc etc) it is for "research ability".

As many older Ph.D's will grudgingly admit their research choice was "kind of made for them" by those assessing them.

The big problem with a Ph.D is that the research is normaly a small increment on existing knowledge and often lacks any real originality.

This is due in part to the people assessing you, they have little way to judge highly original work.

But a pertanent question to ask is not "Has Bruce a Ph.D?" but "Is there a Ph.D for Bruce's originality?".

As far as "standing" in the "field of endeveor" I think Bruce has proved himself way beyond what most Ph.D's could ever hope to do.

Also I suspect that his work on his various systems and the "writing up" he has done would be regarded as sufficient by many.

Daniel WijkSeptember 16, 2009 9:11 AM

Clive Robinson: I agree, there is few people in his field that we have knowledge about who can speak with authority on these matters and come out as credible as Bruce.

Bruce SchneierSeptember 16, 2009 9:12 AM

"A quick google doesn't give much info on cipher modes with tweakable block ciphers. Does anyone know if theres been much work in that direction?"

All normal block cipher modes work with tweakable block ciphers. The tweak is just an additional input that can be used to "personalize" the cipher.

DavidSeptember 16, 2009 12:58 PM

@Bruce 'an additional input that can be used to "personalize" the cipher"


So roughly the same notion as a salt?

RandallSeptember 16, 2009 2:39 PM

@David: With Threefish at least, you can have a different tweak for each block of each message without a performance hit, which isn't true of all salts. For instance, a tweak could be helpful for making a secure but still parallelizable mode for hard disk encryption.

Brad ConteNovember 22, 2009 6:32 PM

For those still interested in more on the definition of a tweakable block cipher, here is a relevant paper: http://www.cs.berkeley.edu/~daw/papers/... .

The Abstract:
----------------
"We propose a new cryptographic primitive, the “tweakable
block cipher.” Such a cipher has not only the usual inputs—message and
cryptographic key—but also a third input, the “tweak.” The tweak serves
much the same purpose that an initialization vector does for CBC mode
or that a nonce does for OCB mode. Our proposal thus brings this feature
down to the primitive block-cipher level, instead of incorporating it only
at the higher modes-of-operation levels. We suggest that (1) tweakable
block ciphers are easy to design, (2) the extra cost of making a block
cipher “tweakable” is small, and (3) it is easier to design and prove
modes of operation based on tweakable block ciphers."

Clive RobinsonNovember 23, 2009 2:38 AM

@ Brad Conte,

"For those still interested in more on the definition of a tweakable block cipher"

Or to put it another way,

"when is a key not a key?

Or more poeticaly "A rose by anyother name would smell as sweet"

There are various answers to this depending on what you change and how.

Back with DES we had a fixed data transposition that gave rise to the idea of modifing the data into the block cipher either in a fixed or changable way (think about the Unix password system).

This gave rise to the idea of "whitening" where you xored the data with a changable value (equivalent of an IV). And also a progamable permutation has been touted for software only systems (the hardware takes up to much real estate). Neither method is in it's self is a secure step but it significantly adds to other issues for cryptoanalysis in a cheap and easy way.

You could look on it as a "pre-ciphering" of the data. I and others at various points in time proposed using a stream cipher instead of a fixed IV to do the same thing but get real strength out of the process for little extra cost (the down side is syncing up the system but there are ways to making it self syncing).

Like wise you can "whiten the key" in various ways before, during and after key expansion. Again by permutation or substitution as a fixed IV or via a stream cipher (which again I and others have proposed at various points in time for both software and hardware implementations).

None of the above in the general case should overly effect the strength of the block cipher design (yes I know there are specific cases to prove the "Don't do it Jim" rule ;)

Then you can look at the actual data ciphering and this is where it can get a bit dodgy on the strength of the cipher.

If you loosly assume that a block cipher is based on a Fiestel network of some kind then you have the one way functions and the reversable mixing functions.

You can "moderately" safely apply whitening in all it's forms to the inputs and outputs of the one way and mixing functions.
You can also take reversable data flow switching (block permutation) on more complex Fiestel mixing as well as the number of rounds. These can and will in most cases effect the strength of the block cipher so considerable care has to be excersised in both the design and selection of the control input.

It is arguable (and has been) that this is a very desirable idea because if somebody copies your design without knowing what is good and bad then you have a system that is always strong for you. But has the highly desirable feature (in some circles) that on occasions it will be considerably weaker for those who's traffic you might wish to look at.

This is kind of doing an end run around the
Kerckhoffs' axiom (restated by Claude Shannon) of "The enemy knows the system". Effectivly it gives your opponent what is occasionaly a "stealth" trojan horse...

You can then start to play with the way the oneway and mixer functions actually work for instance instead of XOR across a byte you might use add/subtract or even a more complex function (a reversable DSP MAD for instance).

One method that has been around for many years is "programable S-Boxes" or State arrays.

The problem is not so much what we call things (whitening, tweekable, programable, etc) but that in many respects they are to general to be specificaly meaningfull (concepts not actuality) except in a clear context.
And as we know from "software specs" this is where things go astray.

Perhaps the "concepts" need a taxonomy developed as a framework in which specific implementations can be pigeon holed.

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 Co3 Systems, Inc..