Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Technology

Preview of New Block Cipher 232

Posted by Hemos from the doesn't-matter-until-peer-testing dept.
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."
This discussion has been archived. No new comments can be posted.

Preview of New Block Cipher More

Preview of New Block Cipher

Comments Filter:

  • does this mean (Score:3, Funny)

    by Anonymous Coward on Thursday March 24, 2005 @10:07PM (#12042559)
    he can beat neo now?
    • No... I cant ping him yet. :-D

    • Re:does this mean (Score:2, Interesting)

      by flaws ( 805277 )
      Reference Code is available for download.

      • Author? Rationale? Trustability? (Score:4, Insightful)

        by billstewart ( 78916 ) on Friday March 25, 2005 @05:07AM (#12044593) Journal
        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? (Score:5, Insightful)

          by Ckwop ( 707653 ) * on Friday March 25, 2005 @06:55AM (#12044875) Homepage

          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.

  • In case of Slashdotting... (Score:5, Funny)

    by Anonymous Coward on Thursday March 24, 2005 @10:09PM (#12042561)
    MD5 of article text: 79592dc553067bfafaa07086c07d2c8a

  • PGP: A Dangerous Program for a Dangerous Time (Score:5, Funny)

    by Anonymous Coward on Thursday March 24, 2005 @10:09PM (#12042564)
    Hello,

    Recently I noticed that my teenage son Ezekiel had begun to encrypt
    his emails with a program called PGP. I was concerned because I'd
    always covertly monitored their email for any hints of illegal
    activity, drug use or interest in the occult - some of his classmates
    have begun playing Dungeons and Dragons and listening to KISS. Since
    Ezekiel was now using PGP, his activites were hidden from me!

    Additionally, I also overheard him talking of using a program called
    Stegasaurus to embed secret information into normal-looking pictures.
    Terrified that my son might be speaking in some sort of sinful code, I
    immediately grounded him for a month. He was only allowed to go to
    school and Bible study.

    Anyways, I've done several days worth of research on this and
    discovered a few things about PGP that I'd like to share with the
    readers of these newsgroups. To begin with, I realized that many of
    the claims made by the creators of PGP are blatently false. Although I
    do not have a background in mathematics (I have an AA in Photography)
    I was easily able to rebuild Ezekiel's private key via his public key
    and one of his encrypted messages.

    Of course I am above-average in intelligence, but PGP is supposedly
    unbreakable! Perhaps crytogrophers aren't as smart as they believe?
    Fortunately in this case Ezekiel was just discussing a girl he met in
    school - a situation I harshly reprimanded him for. However, while PGP
    may be a program with flaws, it got me thinking about other programs.
    Perhaps someone will construct a PGP-like program that cannot be so
    easily broken; one that would take days of computer time to hack!

    My concern with a program like this is that people who use
    cryptography always do so because they have something to hide. A sense
    of guilt and shame seems to drive them. They know that they are doing
    something wrong and desperately want to hide it from the eyes of the
    world (although hiding it from the eyes of God is another matter!
    LOL!)

    A study recently released by the Institute for Family Computing
    revealed that the top three uses of cryptography were for 1)
    "terrorist-related activity" 2) pedophillia and 3) drug abuse. In fact
    as far as I can tell, no legitimate use was on the top ten at all!

    What scares me about this is that law-enforcement agencies will be
    unable to sift through email to find people who are breaking the law,
    or otherwise engaged in suspicious activity. At a time when our nation
    is under siege, I find it disturbing that people are working on
    developing cryptography that cannot be broken, even by our protectors
    in the FBI and CIA! Only those with something to hide truly need
    cryptography.

    Thus I urge cryptogrophers world wide to refrain from working on such
    programs, until our nation is no longer at war. I would ask those of
    other countries to respect our right to self-defense and aid us in our
    time of trouble. Your cryptographic skills can be better put to use
    trying to find terrorists than to assist them.

    • Re:PGP: A Dangerous Program for a Dangerous Time (Score:4, Funny)

      by maroonhat ( 845773 ) on Thursday March 24, 2005 @10:39PM (#12042784)
      Is your son a computer hacker? [adequacy.org]

      ...im quite sorry a site like the one my link points to exists but its hilarious none the less

      • Re:PGP: A Dangerous Program for a Dangerous Time (Score:3, Informative)

        by Anonymous Coward
        adequacy.org is one of those sites that started out as a parody site, and then everyone seemed to forget what the site was really about. Some of the newer posts there (there aren't many, note that the "computer hacker" article you linked is one of the oldest yet still on the front page) are truly scary in their seriousness. I think even Landover Baptist manages to not take itself as seriously as some of adequacy's posters do.
      • I was quite angry that this article existed untill i hit this:

        Your son will probably try to install some hacker software. He may attempt to conceal the presence of the software in some way, but you can usually find any new programs by reading through the programs listed under "Install/Remove Programs" in your control panel. Popular hacker software includes "Comet Cursor", "Bonzi Buddy" and "Flash".


        and realized it was meant to be funny. I hope.
    • 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!
    • Moderation: +5 Funny, Insightful Troll

      Don't act like you didn't know.

    • Recently I noticed that my teenage son Ezekiel had begun to encrypt
      his emails with a program called PGP.

      If my parents named me Ezekiel, I'd try to hide that fact too.

    • So then, why are we posting this anonymously? Exactly what is it YOU are hiding? Is it SATAN?
    • Although Ido not have a background in mathematics (I have an AA in Photography) I was easily able to rebuild Ezekiel's private key via his public key and one of his encrypted messages. Of course I am above-average in intelligence, but PGP is supposedly unbreakable!

      As the United States has known since its founding, all cryptographic algorithms (even the one-time pad) are vulnerable to attack via divine revelation, even in the absense of the ciphertext itself. Those able to take advantage of this regularly

    • > My concern with a program like this is that people who use
      > cryptography always do so because they have something to hide.
      > A sense of guilt and shame seems to drive them.
      > They know that they are doing something wrong and desperately
      > want to hide it from the eyes of the world (although hiding
      > it from the eyes of God is another matter! LOL!)

      Dear Mr. Ashcroft,

      My concern with a post like yours is that people who use
      "Anonymous Coward" always do so because they have something to hide.
      A s

  • Review Expertise. (Score:1, Insightful)

    by 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?
    • It's the standard crypto algorithm; I, personally, would be happy if they turn the algorithm over to open peer review. Anything else smacks of security by obscurity to me.

      If the algorithm is openly available and openly reviewed it may well be a viable alternative, though my understanding was that one of the reasons Rijndael was selected as the AES algorithm was it's ease of implementation in hardware and low memory footprint as compared to several of the other contenders.

      If it's not? Snake oil, or at leas

  • Well....maybe (Score:2, Insightful)

    by erick99 ( 743982 )
    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

    • Re:Well....maybe (Score:5, Informative)

      by patchvonbraun ( 837509 ) on Thursday March 24, 2005 @10:28PM (#12042709)
      Immunity in this case meaning that the work factor for mounting the attack is greater or equal to the work factor for brute-forcing the key. If brute-forcing the key costs 2**128 operations, and differential costs 2**129, for example, then you'd be crazy to attempt differential cryptanalysis, when bruting the key is cheaper. I admit to not having RTFP, so I can't evaluate their claim of immunity to DC and LC, but modern ciphers are deliberately designed to be resistant to attack via DC and LC.
    • It's clearly an overstatement. The most they can claim is that it is immune to any known differential or linear cryptanalysis. of course that only proves that their PR peson isn't a mathmatician.
    • Considering the number of "hired guns", and
      the amount of resources poured into various
      3 letter alphabet soup government organizations,
      any reliance upon the "next big thing" in ciphers,
      like ellipse curve encryption, is likely to end
      badly. AES-1 was supposed to have been the hot
      new encryption, but has been found vulnerable.
      I don't expect much better long term security
      with a number of other encryption methods,
      particularly with the "seal of approval" of those
      same 3 letter alphabet soup organizations.

      A CD-R ch
      • This sounds like someone has finally found a use for all of those AOL cd's. A completely new set of pads delivered to your door monthly.
      • A CD-R chock full of books in ANSI text or XML
        or even PDF format could easily provide the basis
        for a lifetime's worth of OTP (One Time Pad)
        encryption.

        Completely unusable. An one-time pad with a structure is insecure. One that is actually text can be broken automatically today, we wrote such a programm in a crypto-lab during my CS studies. Required not much encrypted text either. Some kBs or less.

        • That's only if you use the pad more than once, right? I mean, if it was used only once then there is no way to know when you've decrypted the message properly. This post could be the cypher text of a message, and with however many keys there are available, you could decrypt it into any other message you wanted, and never know which one was right.
          • Unfortunately, no. You can recognise language e.g. from its letter frequency, letter-pair frequency, word frequency, etc.. You can take two arbitrary texts in english. Use one as pad and the other as message. While this may not allow a complete automatic recovery of both texts from the encrypted text only, automated tools can come pretty close. And we are not talking true wizardry here, but more a semester project for some smart undergrads. Any cryptoanalyst will just laugh at this stuff.

            Incidentlially thi
      • A CD-R chock full of books in ANSI text or XML or even PDF format could easily provide the basis for a lifetime's worth of OTP

        Nope. You do not base OTP on blocks of known words. That can be deciphered rather easily. The OTP needs to be random characters. You'd be better off using binary files (but still not as good as a truly random pad). I think you may have confused concepts from a book cipher and OTP.

  • "provably just as secure as AES-128"? Bah. (Score:5, Informative)

    by Jepler ( 6801 ) <jepler@unpythonic.net> on Thursday March 24, 2005 @10:13PM (#12042588) Homepage
    I read the paper. They devote, oh, a page or so to attacks. Proven as secure as AES? bah.
  • If I'll be able to understand how this one works. The only algorithm I've ever understood well enough to write an implementation is RC4. I would like to see a strong algorithm that is fairly simple to understand, but I fear that such a thing is not possible.

  • Go with what is widely used (Score:5, Insightful)

    by John Harrison ( 223649 ) <johnharrison@@@gmail...com> on Thursday March 24, 2005 @10:14PM (#12042597) Homepage Journal
    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.

    • I should probably mention that the above is in no way meant to endorse the use of single DES in the present.
    • Sorry but that argument goes both ways. Just because something is a standard does not everyone is find a fault. No matter what cipher if the person has malicious intent it is a problem, and that is one that we deal with everyday with security vulnerabilities as well.

      Standards have their own share of problems, if one major standard like 3DES is broken and is published, it will take a lot of effort to protect all the systems that use it.

      I am not saying that what is said is the correct view, I am saying

    • Re:Go with what is widely used (Score:5, Interesting)

      by Zeinfeld ( 263942 ) on Friday March 25, 2005 @01:06AM (#12043635) Homepage
      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.

      Whenever a 40 bit cipher turns up the most likely reason is the export restrictions. When TI was doing its work they could not stick to the standard.

      Plus 3DES is not exactly a great cipher, the small block size means that certain attacks become possible after 2^32 blocks of ciphertext, that is only 32 Gb of data which is not a lot of data.

      The TI problem was due to using the same cipher for 15 years without periodic security reviews.

  • Already cracked ! (Score:4, Funny)

    by MajorDick ( 735308 ) on Thursday March 24, 2005 @10:15PM (#12042609)
    Well, I called up DVD Jon , and within about 15 minutes he had a working exploit for the cipher.

    Oh well off to the next

    Nothing to see here already been cracked...move along....

  • Snake Oil? (Score:5, Insightful)

    by Anonymous Coward on Thursday March 24, 2005 @10:15PM (#12042610)
    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? (Score:5, Informative)

      by flaws ( 805277 ) <fl@ws> on Thursday March 24, 2005 @10:36PM (#12042759) Journal
      1) No - it is open source and technically public domain. 2) That is what we are attempting now - the preview is to get it lined up with crypto experts to review. 3) If it gets past 2, then that is something to consider.

      • Re:Snake Oil? (Score:3, Insightful)

        by m0rningstar ( 301842 )
        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
      • Public domain has a very specific legal meaning. Open source is definitely not in the public domain. It is protected by copyright and all of the "open" licenses are precisely that - licenses to use that code (or documentation, images, etc.) in specific ways.

        Of course some companies make the mistake you made... and when they're caught they're usually act surprised to learn that 1) somebody cares and 2) that somebody has enforceable legal rights.

        As for the second comment, that's all anyone serious about se
        • "Public Domain" actually several relevant specific legal meanings.
          • US Technology Export Laws (which were written back when the Free World was the enemy of Communism to prevent Commies from getting militarily useful technology, and kept around much longer as a fiction to prevent citizens from having private communications that the FBI and NSA couldn't wiretap) defines "public domain" essentially as open knowledge that can be freely discussed, at least by academics, without the same limitations as non-publi

    • Re:Snake Oil? (Score:3, Informative)

      by dtfinch ( 661405 ) *
      "Secure Science Corporation"

      Domain Name: SECURESCIENCE.NET
      Registered through: GoDaddy.com
      Created on: 24-Oct-03

      A quick search through the sci.crypt archives suggests that they employ at least one cryptographer who ought to be qualified to tell if it's clearly clearly.

      But my own inexperienced mind tells me that a 4x4 sbox seems awfully small, and that they've put an awful lot of effort into making it efficient in hardware requiring a minimal number of gates. It's not hard to just make a secure cipher, but
      • ... and that they've put an awful lot of effort into making it efficient in hardware requiring a minimal number of gates.

        Which in my view equates to "easier to brute-force." [eff.org] Am I missing something?

        It seems to me that the easier it is to implement in hardware, the more implementations will fit in a single FPGA/ASIC, the smaller/cheaper/faster a hardware-based brute-force attack would be...

        Recommendation: stick with AES. We don't need YAWEA (Yet Another Weak Encryption Algorithm)...
        • A brute force attack on a 128 bit cipher is completely impractical -- even if you made it 256 times easier to implement it in hardware, it would still be completely impractical.

  • Maybe there's something I'm not getting here, (Score:5, Insightful)

    by sporktoast ( 246027 ) on Thursday March 24, 2005 @10:16PM (#12042614) Homepage

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

  • 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?
    • No. Encryption algorithms are supposed to act as one way functions when you don't have the key. If this algorithm is properly implemented (but nothing ever really is), no intrinic property of the algorithm would speed up the cracking process. Going backwards (decryption) *with* a key is faster, but going backwards without a key (cracking) is totally different.

  • Snake-oil... (Score:4, Insightful)

    by rhythmx ( 744978 ) * on Thursday March 24, 2005 @10:28PM (#12042706) Homepage Journal
    "We prove that our design is immune to differential and linear cryptanalysis"

    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:Snake-oil... (Score:2, Interesting)

      by flaws ( 805277 )
      Ironically, Secure Science got an email from Schneier, his quote was "Wow. Definitely not Snake-oil."

    • Re:Snake-oil... (Score:5, Insightful)

      by cpeikert ( 9457 ) <.ude.tim.mula. .ta. .trekiepc.> on Thursday March 24, 2005 @10:38PM (#12042776) Homepage
      "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... (Score:3, Informative)

        by jpetts ( 208163 )
        You can't reliably prove security for anything other than the one-time pad. All you can do is prove that the attcks you have chosen will not work. Attempting to prove security is attmepting to prove a negative: namely that no attack more efficient than brute force exists.

        • Re:Snake-oil... (Score:3, Interesting)

          by viega ( 564643 )
          Another ill-informed post. There's a difference between absolute security and computational security. We can easily build provable security schemes for confidentiality and integrity, where we prove computational security against all possible attacks. It's not as theoretically absolute as a one-time pad because there is a computational bound where there might be some technological breakthrough (but that's very unrealistic). Or, more likely, the very modest assumption made about the underlying block cipher wi
          • We can easily build provable security schemes for confidentiality and integrity, where we prove computational security against all possible attacks.

            No, you can't. Doing this requires proving that P is not equal to NP, which nobody has done. You can prove security against all known attacks, but not against all possible attacks.

            What you probably meant to say is that we can easily build provably secure systems under reasonable number-theoretic assumptions such as hardness of integer factorization or hardne

            • I said originally that there's the underlying assumption that the underlying block cipher is a PRP. The proof of security of the encryption scheme is secure relies on a weak assumption about the block cipher, but the attack then is on the block cipher, not the scheme for using the block cipher. The whole point is that, for the most part, we can prove security for almost everything we need, and can boil it down to a few minor assumptions that people strongly believe to be true (such as AES is a PRP).

  • I wonder... (Score:3, Interesting)

    by Dr.Dubious DDQ ( 11968 ) on Thursday March 24, 2005 @10:34PM (#12042748) Homepage

    ...how badly patent-encumbered these ciphers are going to end up being?

  • Ugh (Score:3, Insightful)

    by TechyImmigrant ( 175943 ) * on Thursday March 24, 2005 @11:01PM (#12042901) Homepage Journal
    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... (Score:5, Insightful)

    by danielrm26 ( 567852 ) * on Thursday March 24, 2005 @11:04PM (#12042919) Homepage
    "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."

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Thursday March 24, 2005 @11:16PM (#12042966)
    Comment removed based on user account deletion

  • I don't get it... (Score:5, Insightful)

    by cperciva ( 102828 ) on Thursday March 24, 2005 @11:16PM (#12042970) Homepage
    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.

  • Compared to... (Score:2, Informative)

    by null-sRc ( 593143 )
    whitenoise labs, a cryptography startup that just got it's algo's patented...

    Company link:
    http://www.whitenoiselabs.com/

    Cryptographic analysis link:
    http://www.whitenoiselabs.com/papers/Wagne r %20Secu rity%20Analysis.pdf

    Performance anaylysis link:
    http://www.whitenoiselabs.com/papers/UVIC%2 0Perfor mance%20Analysis.pdf

    So whitenoise encryption offers a cheaper solution that is mathematically stronger, and computationally order log n complexity where n is filesize (therefore faster too)

    and please tell me w
  • From TFP:
    Our original 256-bit key designs were designed to use the round function to lower the design, implementation and cryptanalysis time. However, all of our attempts were either weak against reduced round related keys attacks or were too inefficient for on-the-fly computation. As a result for this design we reduced the key size to 128-bits.

    In general (not just in cryptography, which is certainly not my field), it's a good thing to have an idea how to extend an algorithm when designing it. Here, how

  • More hardware-efficient than Rijndael? (Score:5, Insightful)

    by ca1v1n ( 135902 ) <snook@noSPam.guanotronic.com> on Friday March 25, 2005 @04:57AM (#12044564)
    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.
    • The idea is pipeline. The main round function is 4 layers of FPHT networking. So unroll the cipher [thankgod it's not that large] and you get 32 layers of FPHT networking.

      Now make a pipeline with 32 stages... load key then load plaintext.

      So effectively you have a 2 cycle encrypt operation, you can encrypt to 16 DIFFERENT keys simultaneously, and a "cycle period" is roughly as long as one layer of FPHT.

      Gonna encrypt all to one key? Then precompute the key schedule and load one block per cycle...

      Tom [t
  • To see what its biggest weakness is...its a SECRET KEY TECHNOLOGY! all the wonders of unbreakability that are claimed may be true, let the hoped for flood of reviewers decide that. The whole scheme stands or falls on protection of the keys...I can't afford a courier the way DOD can so I am not sure how I am getting my key sent to my intended secure recipients.
  • A cipher that is more efficient in hardware and therefore more easily brute-forced. What will they come up with next?

Slashdot Top Deals

Do you suffer painful hallucination? -- Don Juan, cited by Carlos Casteneda

Close