DJB isn't a big believer in the DFSG that defines Debian - much of his software is released under a non-free license that allows gratis redistribution, but not modification. Also he's not primarily famous for his diplomacy skills (although, neither is former DPL Ian Jackson). Finally there's no way on Earth you'd get him to take the job; it would mean sinking far too much time into things that didn't really interest him.
After I play GTA, I want to go up to stopped cars, open the driver door, punch the driver in the head, drag them out of their car, steal it and drive off.
If you RTFP, what's actually being patented is the idea of using multiple pointers so that the same item can be in more than one linked list at a time. This idea is also a long way from being novel, but it's slightly different from patenting the linked list. Arguably a doubly-linked list is prior art...
As I remember it, I did not hesitate to register, and I read Slashdot very frequently at the time. You can't have hesitated for more than a day or so between Slashdot introducing registration and you taking it up.
Also, you can't change the name on an account, so remembering that there was a "Richard Steiner" about in the old days wouldn't help - you'd have to prove that you were that person. For those who didn't use a real name to register, that is obviously impossible.
I know someone who got a job with them (though she didn't end up taking it). Her degree isn't a science degree, but she's very smart indeed and has excellent Google-fu; I don't imagine she would find it hard to become very well informed on CCD versus CMOS sensors very quickly indeed.
I've never seen such pessimistic claims for iris recognition. With a false accept rate of 1/1000 to 1/10000, you can achieve a false accept rate of pretty much zero. I respect Simon Davies, but I'm not sure he has his facts right here.
Yeah, there are ways of doing without the muddle for that problem, and indeed there are entire protocols that can be proven secure without the random oracle model. However most practical protocols still rely on the RH (which allows better hardness assumptions), and for that muddle is unavoidable because we don't have a way of defining what it means to be "like a random oracle", and indeed there are some proofs that this goal is unattainable.
Really, if you're worried about eg AES being broken you're worrying about the wrong security issues. That isn't where our problems lie.
And who would you trust to generate the shared N that everybody uses?
Write your own bignum package and run it on an un-networked computer.
For some applications, everybody has to share the same hash function. If the hash function is SDLH, then whoever generated N can break the application. By contrast, Rijmen has no special advantage in breaking WHIRLPOOL-based applications.
I did just that not long ago in 100% C code (Visual C++) using only a small __asm function to read the Pentium CPU cycle counter and the CString 'datatype'. FWIW, it generated 2 1024(+) bit 100% provable prime numbers that could be multiplied together into a modulus in under 10 minutes on a friend's 2.8 GHz Windows PC.
Good for you - this sort of code is fun to write and good programming practice, and the math behind provable primes is cool. Bear in mind, though, that there's no problem with Rabin-Miller-based prime generation in pratice - the probability of a false positive from RM is much less than the probability of a false positive due to a hardware glitch.
Concerning (1), SHA-512 is the largest secure fixed-length hash around that I know of, has only 256 bits of security. What if you need more?
The problem is that SDLH requires many more bits of output from the same level of security.
SHA-512 has 512 bits of output and the best attack currently known requires 2^256 work - vastly, vastly more than we could ever imagine doing in the next century. By contrast, an SDLH based on RSA-200 would have 663 bits of output, but it's been demonstrated that we can break a modulus that size today. To be as confident of the security as we are of SHA-256, the output of SDLH would have to be thousands of bits long - that would be really quite impractical for many protocols.
By the way, you really don't need more than 256 bits of security. Remember what Bruce Schneier says about the stake in the ground.
I'm not a cryptographer but I know how RSA works.
I am a cryptographer, and you may be surprised about how much there is to learn about how RSA works. The random oracle model is at the heart of the proofs of security for protocols based on RSA. The proof is there to show that the only way to break the protocol is to find an efficient way to solve the RSA problem. The proof says "OK, supposing we had a random oracle, accessible to all parties including the attacker, and it returns random fixed-length outputs given arbitrary-length inputs. Could you break it then?" For practical protocols, we substitute a hash function for the random oracle. When we do that, we're making an assumption that the hash function has basically no interesting structure at all that could be useful to an attacker. It's pretty clear that the output of SDLH has lots of structure - the only property we can really be confident of is that it's collision-resistant, and that's not nearly enough.
To put it another way, strong cryptography is a mixture of mathematics and muddle. If RSA is providing the mathematics, the hash function provides the muddle. A hash function based on a mathematical problem doesn't provide enough muddle to use here.
Sorry I haven't gone into more detail here. The random oracle model is quite hard to explain briefly - you should read Bellare and Rogaway's "Random Oracles Are Practical" if you want to discuss this further.
SDLH can only be broken by throwing fast and/or exotic hardware or more efficient integer factorization algorithms at it. Can the same be said of the successor to SHA-512 when/if it gets broken? Remember how the NSA tweaked DES to frustrate differential cryptanalysis before other people 'rediscovered' it?
Indeed, and it turns out that DES is surprisingly strong for its keysize, even though it was designed in the dark ages - brute force is still the most
And who would you trust to generate the shared N that everybody uses? Whoever knows p and q will trivially be able to break the hash function every way you can.
Other serious problems with this hash function are (1) The output is much too long (2) it's far too regular to substitute for a random oracle where one is needed, and (3) it's much, much too slow.
It's cool - and the proof is cool - but it's not a serious contender for normal applications.
Not hash functions at all: ADLER32, CRC32 (collisions trivial to make) Broken: MD2, MD4, MD5, SHA-1, PANAMA Suspect after recent attacks, vulnerable to generic MD attacks: TIGER, RIPEMD-160 Very, very slow: SHA-2
This doesn't make any sense to me at all. Studied as theoretical objects, hash functions are "keyed" just as ciphers are. Just like ciphers, they are strong only against an attacker with limited computing power, not against an infinitely powerful adversary. Just like ciphers, we have no way of proving them secure, but through crypatanalysis we gain confidence in them.
And quantum computing has nothing to do with it; there are algorithms that are believed to be strong even in the face of quantum computing, and for symmetric primitives like block ciphers and hash functions, quantum computing is not a big problem.
I disagree. The AES competition really galvanized the research community and resulted in some exciting innovations in cryptography - eg the application of bitslicing to the construction of ordinary primitives a la Serpent - and cryptanalsysis - eg Lucks's "saturation attack". And we're seeing similar effects with the eSTREAM competition, which in turn results from the way that all the stream ciphers proposed for NESSIE were broken.
The unfortunate thing is that in order to win this competition, the hash function submitted will have to be pretty conservative - very much like the SHA-512 family. There isn't time to analyze anything really new and have enough confidence in its security to bless it as the new standard for ever on. But if these attacks (and especially the recent attacks on the whole Merkle-Damgard structure) show us anything, it is that the old way turns out not to be the best way to build hash functions, and that more innovative ideas (eg Daemen et al's "belt and mill" proposal RADIOGATUN) should be the way forward.
What we need is for NIST to pull the rug under everyone near the end, and say "thanks for putting huge amounts of energy and hard work into designing and attacking all these hash functions, now you can all make new proposals based on what we've all learned and we'll start over again!"
This is what you get with DRE
on
Who won?
·
· Score: 1
To those pooh-poohing this sort of investigation: with a voting system as untrustworthy as DRE, this is the inevitable outcome. Poring over exit polls looking for voting pattern discrepancies is the only way to have any idea if the machines are accurately reporting the vote. If you don't like it, join the campaign for a voting system that can be seen to be fair on its own merits.
A constant IV in CBC mode can leak information about the plaintext, but it doesn't make it any easier to crack the key. In this instance AIUI the key is only used once, so I don't think there are any attacks.
Just to correct some other misinformation in this thread: a constant IV doesnt' make a "dictionary attack" noticeably easier. The ciphertext isn't "completely random" unless you're using a one time pad, but it may be (and usually should be) indistinguishable from random. It's indistinguishable from random if and only if you're unable to make a good guess about a single bit given the other bits (IIRC). However a distinguishing attack does not imply that key material is leaked by any means.
Still, the choice of CBC mode shows that they didn't have the best expertise on board - these days CTR mode is more often the mode of choice.
If you see people making assertions about cryptographic topics such as these on Slashdot, feel free to comment on my journal asking me to comment on them and if it's within my expertise I'll try to clarify.
Search for all the comments referencing "badscience" or "Goldacre" for the scoop on this nonsense. In summary - a PR firm paid some greedy shill to spout this nonsense as part of an advertising campaign. It's pseudoscience, unrelated to real psychology.
Modern DVCSs also support very lightweight branching with easy and powerful merging between them. And with appropriate automated build/test tools, you should be able to integrate to the main branch on a daily or weekly basis, not wait for months for code to propogate like this guy describes.
The modern DVCSs would all do better
on
Why Vista Took So Long
·
· Score: 3, Interesting
From the article:
"Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes."
Monotone, BitKeeper, git, bzr, and so on would all handle this situation efficiently and gracefully; all the repositories can sync to each other and none need be more than a few minutes out of date. Amazing that Microsoft's solution is so poor by comparison
Slashdot Mirror
I know how he comes across online, but I found him very likeable in person - and not just because he gave me money when I first met him...
His software does sometimes seem pretty idiosyncratic.
DJB isn't a big believer in the DFSG that defines Debian - much of his software is released under a non-free license that allows gratis redistribution, but not modification. Also he's not primarily famous for his diplomacy skills (although, neither is former DPL Ian Jackson). Finally there's no way on Earth you'd get him to take the job; it would mean sinking far too much time into things that didn't really interest him.
After I play GTA, I want to go up to stopped cars, open the driver door, punch the driver in the head, drag them out of their car, steal it and drive off.
And I can't even drive.
If you RTFP, what's actually being patented is the idea of using multiple pointers so that the same item can be in more than one linked list at a time. This idea is also a long way from being novel, but it's slightly different from patenting the linked list. Arguably a doubly-linked list is prior art...
As I remember it, I did not hesitate to register, and I read Slashdot very frequently at the time. You can't have hesitated for more than a day or so between Slashdot introducing registration and you taking it up.
Also, you can't change the name on an account, so remembering that there was a "Richard Steiner" about in the old days wouldn't help - you'd have to prove that you were that person. For those who didn't use a real name to register, that is obviously impossible.
I know someone who got a job with them (though she didn't end up taking it). Her degree isn't a science degree, but she's very smart indeed and has excellent Google-fu; I don't imagine she would find it hard to become very well informed on CCD versus CMOS sensors very quickly indeed.
I've never seen such pessimistic claims for iris recognition. With a false accept rate of 1/1000 to 1/10000, you can achieve a false accept rate of pretty much zero. I respect Simon Davies, but I'm not sure he has his facts right here.
Yeah, there are ways of doing without the muddle for that problem, and indeed there are entire protocols that can be proven secure without the random oracle model. However most practical protocols still rely on the RH (which allows better hardness assumptions), and for that muddle is unavoidable because we don't have a way of defining what it means to be "like a random oracle", and indeed there are some proofs that this goal is unattainable.
Really, if you're worried about eg AES being broken you're worrying about the wrong security issues. That isn't where our problems lie.
For some applications, everybody has to share the same hash function. If the hash function is SDLH, then whoever generated N can break the application. By contrast, Rijmen has no special advantage in breaking WHIRLPOOL-based applications.
Good for you - this sort of code is fun to write and good programming practice, and the math behind provable primes is cool. Bear in mind, though, that there's no problem with Rabin-Miller-based prime generation in pratice - the probability of a false positive from RM is much less than the probability of a false positive due to a hardware glitch.
The problem is that SDLH requires many more bits of output from the same level of security.
SHA-512 has 512 bits of output and the best attack currently known requires 2^256 work - vastly, vastly more than we could ever imagine doing in the next century. By contrast, an SDLH based on RSA-200 would have 663 bits of output, but it's been demonstrated that we can break a modulus that size today. To be as confident of the security as we are of SHA-256, the output of SDLH would have to be thousands of bits long - that would be really quite impractical for many protocols.
By the way, you really don't need more than 256 bits of security. Remember what Bruce Schneier says about the stake in the ground.
I am a cryptographer, and you may be surprised about how much there is to learn about how RSA works. The random oracle model is at the heart of the proofs of security for protocols based on RSA. The proof is there to show that the only way to break the protocol is to find an efficient way to solve the RSA problem. The proof says "OK, supposing we had a random oracle, accessible to all parties including the attacker, and it returns random fixed-length outputs given arbitrary-length inputs. Could you break it then?" For practical protocols, we substitute a hash function for the random oracle. When we do that, we're making an assumption that the hash function has basically no interesting structure at all that could be useful to an attacker. It's pretty clear that the output of SDLH has lots of structure - the only property we can really be confident of is that it's collision-resistant, and that's not nearly enough.
To put it another way, strong cryptography is a mixture of mathematics and muddle. If RSA is providing the mathematics, the hash function provides the muddle. A hash function based on a mathematical problem doesn't provide enough muddle to use here.
Sorry I haven't gone into more detail here. The random oracle model is quite hard to explain briefly - you should read Bellare and Rogaway's "Random Oracles Are Practical" if you want to discuss this further.
Indeed, and it turns out that DES is surprisingly strong for its keysize, even though it was designed in the dark ages - brute force is still the most
And who would you trust to generate the shared N that everybody uses? Whoever knows p and q will trivially be able to break the hash function every way you can.
Other serious problems with this hash function are (1) The output is much too long (2) it's far too regular to substitute for a random oracle where one is needed, and (3) it's much, much too slow.
It's cool - and the proof is cool - but it's not a serious contender for normal applications.
Not hash functions at all: ADLER32, CRC32 (collisions trivial to make)
Broken: MD2, MD4, MD5, SHA-1, PANAMA
Suspect after recent attacks, vulnerable to generic MD attacks: TIGER, RIPEMD-160
Very, very slow: SHA-2
This doesn't make any sense to me at all. Studied as theoretical objects, hash functions are "keyed" just as ciphers are. Just like ciphers, they are strong only against an attacker with limited computing power, not against an infinitely powerful adversary. Just like ciphers, we have no way of proving them secure, but through crypatanalysis we gain confidence in them.
And quantum computing has nothing to do with it; there are algorithms that are believed to be strong even in the face of quantum computing, and for symmetric primitives like block ciphers and hash functions, quantum computing is not a big problem.
I disagree. The AES competition really galvanized the research community and resulted in some exciting innovations in cryptography - eg the application of bitslicing to the construction of ordinary primitives a la Serpent - and cryptanalsysis - eg Lucks's "saturation attack". And we're seeing similar effects with the eSTREAM competition, which in turn results from the way that all the stream ciphers proposed for NESSIE were broken.
Whirlpool is pretty slow. What do you think of Radiogatun?
The unfortunate thing is that in order to win this competition, the hash function submitted will have to be pretty conservative - very much like the SHA-512 family. There isn't time to analyze anything really new and have enough confidence in its security to bless it as the new standard for ever on. But if these attacks (and especially the recent attacks on the whole Merkle-Damgard structure) show us anything, it is that the old way turns out not to be the best way to build hash functions, and that more innovative ideas (eg Daemen et al's "belt and mill" proposal RADIOGATUN) should be the way forward.
What we need is for NIST to pull the rug under everyone near the end, and say "thanks for putting huge amounts of energy and hard work into designing and attacking all these hash functions, now you can all make new proposals based on what we've all learned and we'll start over again!"
To those pooh-poohing this sort of investigation: with a voting system as untrustworthy as DRE, this is the inevitable outcome. Poring over exit polls looking for voting pattern discrepancies is the only way to have any idea if the machines are accurately reporting the vote. If you don't like it, join the campaign for a voting system that can be seen to be fair on its own merits.
You may be interested to know that Schneier devoted a blog entry to linking to this description:
u rity_theate.html
http://www.schneier.com/blog/archives/2007/01/sec
A constant IV in CBC mode can leak information about the plaintext, but it doesn't make it any easier to crack the key. In this instance AIUI the key is only used once, so I don't think there are any attacks.
Just to correct some other misinformation in this thread: a constant IV doesnt' make a "dictionary attack" noticeably easier. The ciphertext isn't "completely random" unless you're using a one time pad, but it may be (and usually should be) indistinguishable from random. It's indistinguishable from random if and only if you're unable to make a good guess about a single bit given the other bits (IIRC). However a distinguishing attack does not imply that key material is leaked by any means.
Still, the choice of CBC mode shows that they didn't have the best expertise on board - these days CTR mode is more often the mode of choice.
If you see people making assertions about cryptographic topics such as these on Slashdot, feel free to comment on my journal asking me to comment on them and if it's within my expertise I'll try to clarify.
Search for all the comments referencing "badscience" or "Goldacre" for the scoop on this nonsense. In summary - a PR firm paid some greedy shill to spout this nonsense as part of an advertising campaign. It's pseudoscience, unrelated to real psychology.
Not full colour ads, but product placement...
In this instance, it turns out, the ads had no bunnyfoot :-)
Er, I think that comment was meant as a joke about the low user ID.
I'm not sure I buy your argument, by the way. Slashdot was always crap. But somehow I keep coming back.
It's been known...
Modern DVCSs also support very lightweight branching with easy and powerful merging between them. And with appropriate automated build/test tools, you should be able to integrate to the main branch on a daily or weekly basis, not wait for months for code to propogate like this guy describes.
From the article:
"Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes."
Monotone, BitKeeper, git, bzr, and so on would all handle this situation efficiently and gracefully; all the repositories can sync to each other and none need be more than a few minutes out of date. Amazing that Microsoft's solution is so poor by comparison