Slashdot Mirror
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."
The moral of the story: stick to the standards people.
Lasers Controlled Games!
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.
but what is "casual peer review" and why would it be desired (over perhaps more in depth peer review) for an encryption technology?
In a related story, the IRS has recently ruled that the cost of Windows upgrades can NOT be deducted as a gambling loss.
"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.
"You keep using this word. I don't think it means what you think it means."
dmiessler.com -- grep understanding knowledge
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.
Tarsnap: Online backups for the truly paranoid
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.
WARNING: there is a trojan on your
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.