Preview of New Block Cipher

flaws writes "Secure Science Corp. is offering a preview of one of the 3 ciphers they will be publishing througout the year. The CS2-128 cipher is a 128-bit block cipher with a 128 bit key. This cipher is proposed as a hardware alternative to AES, being that it is more efficient in hardware, simpler to implement, and comparably secure to AES-128. The preview of the CS2-128 cipher proposed is in html form and will be available in a published format at the end of April. At this time, requests are made for casual peer review and implementation. Secure Science will be offering a challenge at the end of April, introducing the cipher to the public. This ciphers implementation and usage will be offered in multiple hardware devices, such as wireless routers, cell-phones, and storage management hardware."

Comments

Review Expertise.

[Anonymous Coward]

"Secure Science Corp. is offering a preview of one of the 3 ciphers they will be publishing througout the year."

And how many people will have the expertise to provide a "review" that'll satisfy everyone?

Well....maybe

[erick99]

We prove that our design is immune to differential and linear cryptanalysis as well as argue it resists several other known attacks.

Is it really immune? I don't know enough about the subject to understand the paper but that struck me as a bold statement

Go with what is widely used

[John Harrison]

One of the advantages of AES, 3DES and DES is that as heavily used standards they attract a lot of research. You can have a lot of confidence that if there is a weakness it will be discovered and made public. The same is not true of proprietary ciphers. As a example look at the 40 bit encryption used by TI for RFID tags that was recently broken by a bunch of university students. If those students had been malicious they could have broken it and not told anyone. They could have then exploited the weakness for years because the cipher isn't widely studied so it is unlikely that someone else would have bothered to crack it. If TI had simply gone with 3DES there would have been no problem.

The moral of the story: stick to the standards people.

Snake Oil?

[Anonymous Coward]

Top Questions:

1. Is this a proprietary or patented algorithm?

2. Has this algorithm gone through the usual rounds of analysis among the nations top cryptographers?

3. Has it been implemented in a FIPS 140-2 certified cryptographic module?

That should keep them busy.

Re:Snake Oil?

[Anonymous Coward]

FIPS-140 certification can only be granted to modules that implement NIST-approved algorithms such as AES. It is extremely difficult to get NIST to approve any algorithm that isn't already on the list, for primarily economic reasons. Thus, to dismiss a new algorithm because it is not FIPS-140 certified sounds impressive at first glance, but makes no sense in the real world of cryptographic products.

Re:Snake Oil?

[m0rningstar]

You know ... the first two questions and the answers are excellent.

I'm not sure that having it FIPS-140 certified buys a vast amount from a technical perspective above and beyond the first two. It's a necessary step for getting the Federal government to use it, but I'd trust the external peer review prior to that.

However -- there's the two points addressed: open standard and accepted for review. Given some time to analyse and review it, this sounds like a decent addition to the arsenal, IF it passes said review.

(I'm no cryptographer. I don't even play one on /.)

Maybe there's something I'm not getting here,

[sporktoast]

but what is "casual peer review" and why would it be desired (over perhaps more in depth peer review) for an encryption technology?

Hardware DRM here we come!!

[Anonymous Coward]

oh dear...is that the time?

Hardware acceleration

[meestaplu]

Now, I know that it's provably hard to attack a good encryption scheme. However, if this one is easier to implement in hardware -- if the cipher can be hardware accelerated more easily -- does that mean that an attack on this scheme could also be hardware accelerated more easily?

Re:Hardware acceleration

[Anonymous Coward]

As I noted in an earlier comment, every modern private key scheme is designed with hardware acceleration in mind to allow for speedy encryption. If the key is long enough and the system is secure enough to make the only possible attack exhaustive test, it doesn't really matter how fast you can decrypt. If it takes a microsecond per message and you have to run a brute force attack on a message with a 128 bit key, it will take well over a million years to get the plaintext.

-ShadowRanger

Snake-oil...

[rhythmx]

"We prove that our design is immune to differential and linear cryptanalysis"

See Bruce Schneier's "Snake Oil", Warning Sign #8: Security proofs.

"Secure Science will be offering a challenge at the end of April, introducing the cipher to the public."

See: Warning Sign #9: "Cracking contests" and "The Fallacy of Cracking Contests"

All of this may be well and good, but I don't any real engineers are going to be choosing this over AES anytime soon. AES was a competition backed by NIST to replace the current encryption standard (3DES). Most of the world's top cryptographers submitted thier algorithm. Only after a very long and very thourogh peer review process did the NIST declare Rijandel's submission to be the winner, and therefore the new AES standard.

Re:Snake-oil...

[cpeikert]

"We prove that our design is immune to differential and linear cryptanalysis"

See Bruce Schneier's "Snake Oil", Warning Sign #8: Security proofs.

Two things: number one, you can prove immunity to these two kinds of attacks, in a formal, rigorous way. That doesn't mean there are no attacks, but it's decent evidence of security.

Number two, proofs of security are a very good thing. Just because snake-oil salesmen claim to have "proofs of unbreakability" does not mean that security proofs are bad. A rigorous proof of security against a well-specified, formal attack model should inspire lots of confidence. Without security proofs, cryptography would still just be mostly ad-hoc-ery.

Re:Snake-oil...

[ambrosine10]

Really? Source please.

Re:Worse than previewing non-existant products...

[Dr.Dubious DDQ]

things like these need to be kept, yknow, secret....

No, they don't - not if they're GOOD security.

The intention is that with good encryption techniques, the "bad guys" can know all about how the system works...and it will work anyway. What's the point in making sure nobody sees you hiding your key under the doormat (security-through-obscurity) if the key doesn't work for anyone but you anyway?

Ugh

[TechyImmigrant]

Ugh.

1) No decrypt specified. So it doesn't work with many modes.

2) Complete ambiguity in the endianess of the test vectors. Which end is which?

3) Optimized for HW complexity. We have AES for that. We want new ciphers optimized for security.

Easy killer...

[danielrm26]

"This cipher is proposed as a hardware alternative to AES, being that it is more efficient in hardware, simpler to implement, and comparably secure to AES-128."

Comparably secure? The Rijndael algorithm has been around for a pretty long time and has undergone a lot of scrutiny. Wait until this new kid has been around the block for a few years; then we talk about comparisons to Rijndael.

"You keep using this word. I don't think it means what you think it means."

I don't get it...

[cperciva]

Maybe I'm misreading the description, but it looks to me like this is an 8-round cipher with a round function considerably simpler than Rijndael's round function.

Given that 8-round Rijndael is broken, it seems highly optimistic to think that this new cipher will not be broken.

Re:PGP: A Dangerous Program for a Dangerous Time

[TheoMurpse]

interest in the occult - some of his classmates have begun playing Dungeons and Dragons and listening to KISS.

Can you people who are responding not tell it's a joke? Unless this was written 30 years ago or so!

More hardware-efficient than Rijndael?

[ca1v1n]

I've actually designed the encryption end of a synthesizable Rijndael chip. It was lab 5 of ECE 435 at U.Va. Granted, that's a 4 1/2 credit course, and there were only 5 labs, but still. Adding the decryption would have less than doubled the work, and considerably less than doubled the silicon. Implementing AES in hardware is NOT hard. In the name of laziness, I did it in a highly parallel fashion a lot of work that could be serialized to reduce the transistor count by about a factor of 8, before getting to even slightly fancy optimization techniques.

You need some registers, some shifters, and some very minimal control logic. Doing the sbox algorithmically isn't terribly fast and requires a fair amount of logic, so generally you just use a 256 byte ROM for the sbox. With die space being as expensive as it was when DES was being designed, it's understandable that they did some weird things to make it fit on the chip. These days, nobody blinks at 10k transistors, even on embedded devices.

Sure, their 4x4 sbox is going to take a lot less space on the chip, but does that really buy anything? Their design document shows that 32 of them are necessary to do a whole round in a single step, while only 4 are needed for Rijndael. That's 2048 bits of ROM on CS2 and 8192 bits of ROM for Rijndael, but CS2 takes 33 rounds while the 128-bit version of Rijndael takes only 10. The amount of hardware required for comparable throughput is about the same, though Rijndael's pipeline is an order of magnitude shorter, due to fewer rounds and the rounds not having to go through that barrel-shifter network.

Author? Rationale? Trustability?

[billstewart]

Reference code is important, and while the paper's pretty brief, it looks believable at first glance (I'm an engineer who's dealt with lots of crypto, but am not a crypto mathematician) - it claims to have addressed at least the most important popular attacks.

But it doesn't say who wrote the algorithm (just the reference code) - is it someone known to the community? It's written by the anonymous academic "we" - it references a couple of papers by Tom St. Denis, but has the feel of somebody who doesn't natively speak English, and the web version has spelling problems. The paper's about 8 months old - has some version of it been submitted to any of the academic journals, and have any of the published it? fl@ws says later they're working on getting some professionals to look at it, which is a good start (realistically, if the academic community doesn't generate its own buzz, you're going to have to hire credible people to vet it to start to get some attention so that more people will start trying to attack it.) The posting mentions a "challenge", which is usually a bad, bad sign, though this looks better than the usual snake oil that does that.

Things I'd hoped to see that are missing include

• Why should we care? There are lots of crypto algorithms out there, some of which, like the AES candidates, have been thoroughly beaten up by the community. Is there some weakness (esp. with Rijndael) that this addresses?
• "Faster in hardware" - Sometimes hardware's interesting, but only if you're going to sell lots of it; it needs to perform decently in software. There's a bit of discussion of some of the issues, particularly making it fit on 8-bit processors, in case anybody still uses those, but nothing indicating that any speed testing has been done, or indicating what quantities of memory it needs or sensitivity to running on various architectures (e.g. x86 or something with enough registers or ARM or MIPS, 8/16/32/64 bit issues, etc.) The reference code does indicate that it can at least be implemented in C without hopeless quantities of bit-twiddling, which is a good start.
• I couldn't really tell which block modes were useful - CBC, counter-mode, etc. Is there anything different here than AES?
• How well does it parallelize - if you're trying to pump out maximum speed on something other than a discrete 8-bit chip, such as an array of cells in an FPGA or ASIC, does that work ok? Or is the answer simply "go use whichever standard operations mode you like, just as you would with AES or 3DES?
• Is 128 bits long enough for both the key and the block? There was some discussions about originally trying to design for 256-bit keys, but cutting back to 128 for efficiency reasons. If making it fit onto an 8051 is part of your design criteria, that may be necessary, but many algorithms have some encryption modes that aren't as useful because of birthday attacks because the keys are too short.

Re:Author? Rationale? Trustability?

[Ckwop]

Why should we care? There are lots of crypto algorithms out there, some of which, like the AES candidates, have been thoroughly beaten up by the community. Is there some weakness (esp. with Rijndael) that this addresses?

The only "weakness" in AES is that the transform is incomplete. Nobody has turned this into an attack and it's unlikely to become a source of attack.

I couldn't really tell which block modes were useful - CBC, counter-mode, etc. Is there anything different here than AES?

No, modes of operation are independent of the underlying block cipher.

How well does it parallelize - if you're trying to pump out maximum speed on something other than a discrete 8-bit chip, such as an array of cells in an FPGA or ASIC, does that work ok? Or is the answer simply "go use whichever standard operations mode you like, just as you would with AES or 3DES?

I've not read the details of the spec to be able to answer this question. Sorry :(

Is 128 bits long enough for both the key and the block? There was some discussions about originally trying to design for 256-bit keys, but cutting back to 128 for efficiency reasons. If making it fit onto an 8051 is part of your design criteria, that may be necessary, but many algorithms have some encryption modes that aren't as useful because of birthday attacks because the keys are too short.

This isn't really a concern. In order for birthday attacks to come about using CBC, or some other chaining mode, you'd have to encrypt around 2^64 blocks. The block is 128-bit long, which gives 2^4 * 2^64 = 2^68 bytes of encryption before the probabilities become an issue. If you're encrypting that much with a single key, you're insane.

You might think counter mode would help you avoid that problem, but alas, it does not. In a random stream you'd expect each group of 128-bits to be equally probable. With CTR, however, we know that each 128-bit block of the keystream will only be repeated after 2^128 encryptions. This fact allows you to distinquish CTR from random after around, you guessed it, 2^64 encryptions.

Oh btw, donate to Tom St Denis he writes a cool cryptolib.

Simon.