They've gone for the one of the most liberal open source licenses out there X11. This is compatible with GPL and LGPL, doesn't have the "obnoxious advertising clause", and basically gives us enormous freedom to use the product as we see fit. --
1. Lots of people who have an interest in backing up the War on Some Drugs with facts have funded research looking for bad effects. Weak stuff like your point 1 is the best they've done.
2. Maybe so (although sample sizes of 1 are not a good idea) - smoking *anything* is bad for you. Unfortunately its illegal status stands in the way of safter forms of delivery: I don't see Wrigley launching a brand of marijuana chewing gum any time soon.
3. When you say "affect" the immune system, do you mean "to its detriment"? And why is staying in your body for weeks necessarily bad? Henna stays in your hair for weeks...
4. "Doctors are still researching..." sounds scary, means nothing.
5. Studies have shown that nearly everyone who has tried ill-advised drugs like heroin used marijuana first. This is supposed to be surprising? You imagine people saying "Mmm, shoot me up, but don't give me any of that marijuana stuff"? C'mon, think here!
6. Er, what was this supposed to prove exactly?
7. How many of those 165,000 entered those programs voluntarily, without compulsion of any kind from parents, teachers or other authorities?
8. Exactly wrong, the buildup of THC you alluded to earlier tends to mean that increasingly *lower* dosages are needed to get the effect.
I have to say, anyone who can cite your point 5 as evidence in particular is clearly grasping at straws. It bothers me. --
No, not quite. It's not safe, for example, to use the same key twice with RC4: you could do exactly the same demonstration, since RC4 uses the key to generate a stream of pseudorandom numbers, then XORs the key with your message.
It's safe to use the same key many times with a secure block cipher, though you need to worry about chaining modes to avoid providing the same input block twice. It's safe to use the same public key for years with the same caveat.
No, the real take-home message, I'm afraid, is that designing secure cryptosystems is really difficult and you should know a lot about crypto before you field one. Your best bet is still to use PGP. --
Anything that claims to provide a "one-time-pad" for an ordinary PC always provides terrible security in practice. Except under very special circumstances that ordinary users never meet, OTP's are inherently bad security since we don't spend much time exchanging gigabytes of key across secure channels.
PGP is good. PGP works. Use PGP, or it's compatible and free friend GPG. --
Contrary to the report, this doesn't encrypt anything: it's a "bit commitment" protocol, allowing me to irrevocably choose one of two choices without revealing what I chose later. One application of this is fair coin tosses: you and I both choose a bit at random, then reveal them once they're chosen, and if they're the same I win otherwise you win. The commitment protocol stops me waiting until you've revealed your choice and then announcing that mine is the same.
As another poster said, in practice SHA message digests can be used to do the same job more practically, but this offers "unconditional security"; no amount of computing power could be sufficient to break the protocol. --
If we gain the victory I'm anticipating, competition is going to be fiercer among chip makers than ever before. I'm currently running Linux on x86 hardware, but that's solely because it currently gives me the best bangs per buck for what I'm doing and what I want to spend. If that changes, I'm entirely happy to shift with it. All my data, and all my skills will come with me. All my network protocols will stay the same, so I can still interoperate with everyone else. In the end, the instruction set of your processor may come to matter little more than your brand of hard drive. --
Secrecy and obscurity are fundamentally different in an information-theoretic sense. If you want to ask whether a particular fact, compromise of which might break your system, is a proper secret or merely security, ask yourself this: how difficult is it to measure the *entropy* of that fact, expressed as a number of bits unknown to the attacker?
If it's, say, a randomly-generated 56-bit DES key, then the answer is easy: 56 bits. If it's a 1024-bit RSA public key, then it's somewhat harder, but the answer will be around the 1000-bit range.
If it's a passphrase, it's probably around 40 bits or worse - people are very bad at choosing passphrases, so some care has to go into making guessing attacks difficult.
But if it's a particular implementation issue, or an encryption algorithm you're keeping secret, how big is the algorithm in bits? In other words, how big and how regular is the space of algorithms from which it's drawn? Are there perhaps a thousand algorithms that you might have been equally likely to choose instead (10 bits)? Or ten thousand, but some are more likely than others (13 bits or less)? It's almost impossible to make a sensible estimate, and so actually working out how much security you get from keeping it secret isn't possible. *That's* what security through obscurity is and why it's bad. --
Someone should claim the domain name he suggests for succesful Internet IPOs and give it to the KLF, who set fire to a million pounds sterling in the early nineties and made a film, "The KLF Burn a Million Pounds".
...expert opinion has recommended 1024-bit keys for quite a while.
There are real, fielded systems like "Crest" which protect millions of pounds worth of transactions with mandatory 512-bit keys, but this is not on the advice of those who know what they're talking about. --
It seems pretty unlikely that someone as competent as Adi Shamir would get this one wrong by an order of magnitude. It seems likely that if he says it's possible, it probably is. --
The result against RC6 isn't listed in the body, only the header. And AFAICT it's pretty bad for RC6: its security margin just got much lower. It's a twenty round cipher; this attack breaks a 15 round version, and may well be amenable to extension.
I don't think RC6 can survive this. This makes it even more sure that only Twofish and Rijndael can win. --
Please, learn a little more about the subject before spreading FUD. All of these ciphers are fine.
The result against MARS is an equivalent-key attack, for keys *over 1024 bits long*. AES-standard keys (128,192,256-bit) are fine, it's just a wee problem with some extended functionality that the AES doesn't require. And the "tweak" against MARS for a more smartcard-friendly key schedule fixes even this.
The result for Twofish is even weaker: not all subkeys are possible. However, the subkey entropy is quite sufficient to ensure the security of the cipher, and it doesn't lead to a break. See the paper on the subject on the Twofish home page.
And there's nothing listed for RC6 at all!
HPC is big and slow and complex and impossible to analyse; it would be a terrible mistake to bring it into Round 2. CAST-256 was rejected because everything it does, Serpent does better.
I'm happy with the choices NIST made and the reasoning they give. And like everyone else, I think that the final battle will be between Rijndael and Twofish. It's interesting to note that neither of these excellent ciphers are patent-encumbered.
Oh, and it's not 2^128, it's 2^128 + 2^192 + 2^256, a 78-digit number --
Good question, especially since Microsoft employ some pretty well known names in the field (eg Roger Needham). A.sig quote read "Microsoft is an intellectual roach motel: big brains go in, but you don't see anything come out".
Are they just trying to stop anyone else having any ideas by putting the brains out to graze? Your guess is as good as mine. --
To quote from the NIST report on their choice of 5:
"Rijndael
Major security gaps: none known Minor general security gaps: none known Advantages: a. Excellent performance across platforms b. Good security margin [...snip 6 other advantages...] Disadvantages: no significant disadvantages"
Note further that Rijndael is the *only* one of the 15 candidates not to rate a single entry in the "Disadvantages" field.
I don't know what you mean about the "number of cycles". If you mean "rounds", then Twofish uses 16 rounds and Mars 32. Rijndael uses between 10 and 14 rounds depending on key size, but remember that each of those rounds transforms the *entire* block, not half as in Twofish.
I like Twofish a lot, and wouldn't be surprised to see it win, but the more I look at Rijndael the more I like it.
All of the other candidates have serious disadvantages on some platform or other. Twofish's biggest disadvantage is its complexity, though there are some neat things about it, especially the key schedule which is a real advance in crypto technology. --
May I suggest actually reading the NIST document giving the reasons for their decisions?
CAST-256 wasn't chosen because of its mediocre performance and large ROM requirements on smartcards. It's the predecessor, CAST-128, that's now used in PGP. Note that although CAST is proven secure against certain classes of attack, it's also proven that you can build a weak cipher which passes the same tests.
HPC was never a serious contender: it's a bad performer on all platforms except 64-bit microprocessors, and it's too weird to be analysed in the time available.
This contest will have advanced the art of block cipher design and analysis whoever wins, and we'll have gained some damn good ciphers in the process. --
You can find out about all the Round 2 finalists, and other AES related websites, on NIST's Round 2 page: http://csrc.nist.gov/encryption/aes/round2/round2. htm --
IDEA is neat, but it's (a) slow compared to the alternatives, (b) patented, and (c) only has a 64-bit blocksize, so a dictionary attack (collect all plaintext/ciphertext pairs) is within reach. Read the descriptions of the five finalists, especially Rijndael; if you liked IDEA then you might think it's pretty neat.
There are *many* alternative public key systems; RSA is just the best known, not the fastest or most secure. But there can't be a mathematical solution to the man-in-the-middle attack because it's at least partly a political problem: who's the "legitimate" owner of a particular IP address/section of DNS address space, and who do you trust to certify it?
In practice DNSSEC would do a lot to address this, but it isn't getting implemented due to the usual crypto stupidity reasons. --
Some very strong candidates were dropped this time, but nearly all the algorithms have an area where they're a bit weak, whether it's smart card memory usage or performance on 64-bit, highly parallel machines. Two algorithms are rather good performers right across the board of applications, and those two are Rijndael and Twofish.
I used to think Twofish was the guaranteed winner, but these days I'm inclined more towards Rijndael, which achieves its flexibility in rather simpler ways. Note that Rijndael uses fewer rounds, but every round changes the entire block.
Surprised that MARS made it through. It's fast and clever and designed by Don Coppersmith who was one of the primary DES designers, but it's also pretty weird; of the sixteen rounds, eight are unkeyed mixing stages. --
Perl won't win because I'd guess performance will almost certainly be important, and while Perl is easily fast enough for a variety of real-world tasks (where networks and disks become the bottleneck above a particular performance anyway) it's not designed to win contests like this, where the winning entry will almost certainly be CPU-bound in some central computing core. --
Performance was central to last year's contest, for writing a game-playing algorithm. Read the writeups of last year's: the winning team had to do a great deal of damn clever stuff to get that first place. They called on a lot of resources that it would be hard to beat them without. --
Pleasure is good. Sex is a great way to get to know people. Don't let guilt tell you that because it's fun it must be Long Term Bad: lots of pleasure can make for a good life. --
Slashdot Mirror
They've gone for the one of the most liberal open source licenses out there X11. This is compatible with GPL and LGPL, doesn't have the "obnoxious advertising clause", and basically gives us enormous freedom to use the product as we see fit.
--
Check out GJ:
- -
http://www.cs.bell-labs.com/~wadler/pizza/gj/
1. Lots of people who have an interest in backing up the War on Some Drugs with facts have funded research looking for bad effects. Weak stuff like your point 1 is the best they've done.
2. Maybe so (although sample sizes of 1 are not a good idea) - smoking *anything* is bad for you. Unfortunately its illegal status stands in the way of safter forms of delivery: I don't see Wrigley launching a brand of marijuana chewing gum any time soon.
3. When you say "affect" the immune system, do you mean "to its detriment"? And why is staying in your body for weeks necessarily bad? Henna stays in your hair for weeks...
4. "Doctors are still researching..." sounds scary, means nothing.
5. Studies have shown that nearly everyone who has tried ill-advised drugs like heroin used marijuana first. This is supposed to be surprising? You imagine people saying "Mmm, shoot me up, but don't give me any of that marijuana stuff"? C'mon, think here!
6. Er, what was this supposed to prove exactly?
7. How many of those 165,000 entered those programs voluntarily, without compulsion of any kind from parents, teachers or other authorities?
8. Exactly wrong, the buildup of THC you alluded to earlier tends to mean that increasingly *lower* dosages are needed to get the effect.
I have to say, anyone who can cite your point 5 as evidence in particular is clearly grasping at straws. It bothers me.
--
No, not quite. It's not safe, for example, to use the same key twice with RC4: you could do exactly the same demonstration, since RC4 uses the key to generate a stream of pseudorandom numbers, then XORs the key with your message.
It's safe to use the same key many times with a secure block cipher, though you need to worry about chaining modes to avoid providing the same input block twice. It's safe to use the same public key for years with the same caveat.
No, the real take-home message, I'm afraid, is that designing secure cryptosystems is really difficult and you should know a lot about crypto before you field one. Your best bet is still to use PGP.
--
Anything that claims to provide a "one-time-pad" for an ordinary PC always provides terrible security in practice. Except under very special circumstances that ordinary users never meet, OTP's are inherently bad security since we don't spend much time exchanging gigabytes of key across secure channels.
PGP is good. PGP works. Use PGP, or it's compatible and free friend GPG.
--
...anyone else want to fill in the other entries? VisiCorp invented the spreadsheet, but I can't remember the names of the people.
--
Contrary to the report, this doesn't encrypt anything: it's a "bit commitment" protocol, allowing me to irrevocably choose one of two choices without revealing what I chose later. One application of this is fair coin tosses: you and I both choose a bit at random, then reveal them once they're chosen, and if they're the same I win otherwise you win. The commitment protocol stops me waiting until you've revealed your choice and then announcing that mine is the same.
As another poster said, in practice SHA message digests can be used to do the same job more practically, but this offers "unconditional security"; no amount of computing power could be sufficient to break the protocol.
--
If we gain the victory I'm anticipating, competition is going to be fiercer among chip makers than ever before. I'm currently running Linux on x86 hardware, but that's solely because it currently gives me the best bangs per buck for what I'm doing and what I want to spend. If that changes, I'm entirely happy to shift with it. All my data, and all my skills will come with me. All my network protocols will stay the same, so I can still interoperate with everyone else. In the end, the instruction set of your processor may come to matter little more than your brand of hard drive.
--
Secrecy and obscurity are fundamentally different in an information-theoretic sense. If you want to ask whether a particular fact, compromise of which might break your system, is a proper secret or merely security, ask yourself this: how difficult is it to measure the *entropy* of that fact, expressed as a number of bits unknown to the attacker?
If it's, say, a randomly-generated 56-bit DES key, then the answer is easy: 56 bits. If it's a 1024-bit RSA public key, then it's somewhat harder, but the answer will be around the 1000-bit range.
If it's a passphrase, it's probably around 40 bits or worse - people are very bad at choosing passphrases, so some care has to go into making guessing attacks difficult.
But if it's a particular implementation issue, or an encryption algorithm you're keeping secret, how big is the algorithm in bits? In other words, how big and how regular is the space of algorithms from which it's drawn? Are there perhaps a thousand algorithms that you might have been equally likely to choose instead (10 bits)? Or ten thousand, but some are more likely than others (13 bits or less)? It's almost impossible to make a sensible estimate, and so actually working out how much security you get from keeping it secret isn't possible. *That's* what security through obscurity is and why it's bad.
--
sql*kitten is at least sincere, though given the things he's sincere about it's hard to tell if that's a good thing.
--
Someone should claim the domain name he suggests for succesful Internet IPOs and give it to the KLF, who set fire to a million pounds sterling in the early nineties and made a film, "The KLF Burn a Million Pounds".
--
...expert opinion has recommended 1024-bit keys for quite a while.
There are real, fielded systems like "Crest" which protect millions of pounds worth of transactions with mandatory 512-bit keys, but this is not on the advice of those who know what they're talking about.
--
It seems pretty unlikely that someone as competent as Adi Shamir would get this one wrong by an order of magnitude. It seems likely that if he says it's possible, it probably is.
--
The result against RC6 isn't listed in the body, only the header. And AFAICT it's pretty bad for RC6: its security margin just got much lower. It's a twenty round cipher; this attack breaks a 15 round version, and may well be amenable to extension.
I don't think RC6 can survive this. This makes it even more sure that only Twofish and Rijndael can win.
--
Please, learn a little more about the subject before spreading FUD. All of these ciphers are fine.
The result against MARS is an equivalent-key attack, for keys *over 1024 bits long*. AES-standard keys (128,192,256-bit) are fine, it's just a wee problem with some extended functionality that the AES doesn't require. And the "tweak" against MARS for a more smartcard-friendly key schedule fixes even this.
The result for Twofish is even weaker: not all subkeys are possible. However, the subkey entropy is quite sufficient to ensure the security of the cipher, and it doesn't lead to a break. See the paper on the subject on the Twofish home page.
And there's nothing listed for RC6 at all!
HPC is big and slow and complex and impossible to analyse; it would be a terrible mistake to bring it into Round 2. CAST-256 was rejected because everything it does, Serpent does better.
I'm happy with the choices NIST made and the reasoning they give. And like everyone else, I think that the final battle will be between Rijndael and Twofish. It's interesting to note that neither of these excellent ciphers are patent-encumbered.
Oh, and it's not 2^128, it's 2^128 + 2^192 + 2^256, a 78-digit number
--
Good question, especially since Microsoft employ some pretty well known names in the field (eg Roger Needham). A .sig quote read "Microsoft is an intellectual roach motel: big brains go in, but you don't see anything come out".
Are they just trying to stop anyone else having any ideas by putting the brains out to graze? Your guess is as good as mine.
--
To quote from the NIST report on their choice of 5:
"Rijndael
Major security gaps: none known
Minor general security gaps: none known
Advantages:
a. Excellent performance across platforms
b. Good security margin
[...snip 6 other advantages...]
Disadvantages: no significant disadvantages"
Note further that Rijndael is the *only* one of the 15 candidates not to rate a single entry in the "Disadvantages" field.
I don't know what you mean about the "number of cycles". If you mean "rounds", then Twofish uses 16 rounds and Mars 32. Rijndael uses between 10 and 14 rounds depending on key size, but remember that each of those rounds transforms the *entire* block, not half as in Twofish.
I like Twofish a lot, and wouldn't be surprised to see it win, but the more I look at Rijndael the more I like it.
All of the other candidates have serious disadvantages on some platform or other. Twofish's biggest disadvantage is its complexity, though there are some neat things about it, especially the key schedule which is a real advance in crypto technology.
--
May I suggest actually reading the NIST document giving the reasons for their decisions?
CAST-256 wasn't chosen because of its mediocre performance and large ROM requirements on smartcards. It's the predecessor, CAST-128, that's now used in PGP. Note that although CAST is proven secure against certain classes of attack, it's also proven that you can build a weak cipher which passes the same tests.
HPC was never a serious contender: it's a bad performer on all platforms except 64-bit microprocessors, and it's too weird to be analysed in the time available.
This contest will have advanced the art of block cipher design and analysis whoever wins, and we'll have gained some damn good ciphers in the process.
--
That was a public key method, a bit faster but no big deal. This competition is for secret key algorithms, a whole different ball game.
If you'd like to keep track of happenings in the crypto world, read the Cryptogram:
http://www.counterpane.com/crypto-gram.html
--
You can find out about all the Round 2 finalists, and other AES related websites, on NIST's Round 2 page: http://csrc.nist.gov/encryption/aes/round2/round2. htm
--
IDEA is neat, but it's (a) slow compared to the alternatives, (b) patented, and (c) only has a 64-bit blocksize, so a dictionary attack (collect all plaintext/ciphertext pairs) is within reach. Read the descriptions of the five finalists, especially Rijndael; if you liked IDEA then you might think it's pretty neat.
There are *many* alternative public key systems; RSA is just the best known, not the fastest or most secure. But there can't be a mathematical solution to the man-in-the-middle attack because it's at least partly a political problem: who's the "legitimate" owner of a particular IP address/section of DNS address space, and who do you trust to certify it?
In practice DNSSEC would do a lot to address this, but it isn't getting implemented due to the usual crypto stupidity reasons.
--
Some very strong candidates were dropped this time, but nearly all the algorithms have an area where they're a bit weak, whether it's smart card memory usage or performance on 64-bit, highly parallel machines. Two algorithms are rather good performers right across the board of applications, and those two are Rijndael and Twofish.
I used to think Twofish was the guaranteed winner, but these days I'm inclined more towards Rijndael, which achieves its flexibility in rather simpler ways. Note that Rijndael uses fewer rounds, but every round changes the entire block.
Surprised that MARS made it through. It's fast and clever and designed by Don Coppersmith who was one of the primary DES designers, but it's also pretty weird; of the sixteen rounds, eight are unkeyed mixing stages.
--
Perl won't win because I'd guess performance will almost certainly be important, and while Perl is easily fast enough for a variety of real-world tasks (where networks and disks become the bottleneck above a particular performance anyway) it's not designed to win contests like this, where the winning entry will almost certainly be CPU-bound in some central computing core.
--
Performance was central to last year's contest, for writing a game-playing algorithm. Read the writeups of last year's: the winning team had to do a great deal of damn clever stuff to get that first place. They called on a lot of resources that it would be hard to beat them without.
--
Pleasure is good. Sex is a great way to get to know people. Don't let guilt tell you that because it's fun it must be Long Term Bad: lots of pleasure can make for a good life.
--