Preview of New Block Cipher 232
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."
Review Expertise. (Score:1, Insightful)
And how many people will have the expertise to provide a "review" that'll satisfy everyone?
Well....maybe (Score:2, Insightful)
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 (Score:5, Insightful)
The moral of the story: stick to the standards people.
Snake Oil? (Score:5, Insightful)
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.
Maybe there's something I'm not getting here, (Score:5, Insightful)
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!! (Score:1, Insightful)
Hardware acceleration (Score:2, Insightful)
Snake-oil... (Score:4, Insightful)
See Bruce Schneier's "Snake Oil" [schneier.com], 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" [schneier.com]
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:Worse than previewing non-existant products... (Score:4, Insightful)
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?
Re:Hardware acceleration (Score:1, Insightful)
-ShadowRanger
Re:Snake-oil... (Score:5, Insightful)
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.
Ugh (Score:3, Insightful)
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.
Re:Snake-oil... (Score:3, Insightful)
Easy killer... (Score:5, Insightful)
"You keep using this word. I don't think it means what you think it means."
I don't get it... (Score:5, Insightful)
Given that 8-round Rijndael is broken, it seems highly optimistic to think that this new cipher will not be broken.
Re:Snake Oil? (Score:1, Insightful)
Re:Snake Oil? (Score:3, Insightful)
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
Re:PGP: A Dangerous Program for a Dangerous Time (Score:2, Insightful)
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? (Score:5, Insightful)
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? (Score:4, Insightful)
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
Re:Author? Rationale? Trustability? (Score:5, Insightful)
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.