PayPal has essentially none of the cool features considered desirable for a cryptographic cash protocol, so there's still plenty of room for competition based on better technology. Check out the Lucre home page for details of a (seemingly) patent-free system for providing untraceable electronic cash. --
For all practical purposes, DES takes a 56-bit key. OK, so the standards specify that you have to have eight extra "parity" values but they're of no cryptographic value; it's not really accurate to refer to them as key bits, they're more like key padding bits.
A real 64-bit key is pretty hard to crack; the distributed efforts to crack 64-bit RC5 are still running and won't finish for some years yet.
I should also point out that the export controls have been relaxed considerably, and it now seems to be legal to export strong crypto like PGP from the USA... --
Whether or not you distribute Qt, it's illegal to distribute KDE binaries because their dependency on Qt makes it a contravention of the GPL. Note that KDE includes some GPL code that was not explicitly contributed to the KDE project, so even if they wanted to add the extra permission needed to distribute KDE binaries they'd have to get the signatures of non-KDE developers to do it. IIRC, at least one developer whose GPL code is used in the project has indicated that he would *not* give such permission: L. Peter Deutsch, author of Ghostscript. --
UK side people might want to check out my employer, DataCash Ltd (www.datacash.com). We provide credit and debit card clearing to quite a few big players in the UK, including Tiny Computer Ltd., Epson UK Ltd., Breathe.net and QXL. We do multi-currency, and we support lots of clearing houses (Barclays, NatWest, Amex, Bank of Scotland, Royal Bank of Scotland, HSBC, Girobank)
As far as I can tell, we're the most clueful PSP in the UK. I think we're the only ones to have done a proper re-implementation of the banking protocols, and our solutions are implemented using Perl running on Linux. Our client-side code is all open sourced using the X11 license, and we provide Perl, C, and Java implemetations for Unix and NT, as well as more than one shopping cart implementation. And we have some really cool stuff lined up, including eFalcon fraud detection and some other things I can't talk about just now.
My work address is what you might guess (the local part is "paul"), so feel free to mail me any questions, though where appropriate I reserve the right to pass them on to the enquiries address in London! --
RMS isn't arguing that "the Open Source model isn't necessarily the best development model all of the time". RMS argues that free software is just *right*, and prohibiting sharing is, well, wrong. When people argue about these issues as if they are to be judged solely on their efficacy at producing software which doesn't suck, I understand better why RMS rejects the term "Open Source" altogether. --
Combine these shoes with the Ursus Mark VI armoured suit, arrive in your personal helicopter... from Slashdot, I can get the tech I need to become a superhero! Now all I need are some nifty superhero-style weapons! --
If I claim that I had a fight with Mike Tyson and he won, it's relatively unremarkable; the only implausible bit is that we might meet and fight in the first place, not that he wins. If I claim I had a fight with Mike Tyson and I won, such a claim is far less believable.
Thus, if your personal experience tells you that Linux kicks the shit out of MS operating systems for Web server performance, a benchmark test whose results accord with that experience is more believable than one which contradicts it.
Reading the patent, these people clearly do have some familiarity with modern crypto. I still think most of this is bogus but "snake-oil merchants" and "no clue" is putting it a bit strongly. --
NTRU are, as far as I can tell, snake-oil merchants with no clue about real crypto. If anyone can think of an advantage of encrypting a piece of music with lots of short keys over encrypting the entire thing with 256-bit Serpent in counter mode I'd be interested to hear it. --
The point of the method is to make it easy to collect the information, while making it difficult to blame the publishers. Janet Reno is supposed to be able to read it; this is supposed to make it more difficult, legally speaking, to get the information offline. I don't think it'll work but it's not utterly mad. It's not exactly unobvious either.
Your sums are wrong for point 3 as well. If you want a chance on the order of 50%, you'll have to generate around 2^32 pads; that's more like billions than millions. I still think that's too small, but hey, move to a 160-bit identifier (perhaps the SHA-1 of the pad?) and you won't get collisions. --
Crusoe's *peak* power consumption is less than half the *idle* power consumption of this new chip. That's a much larger advantage than a factor of two. Setting even that aside, the difference between three hours of battery life and six is pretty visible and important to customers.
By contrast, AMD seem to barely pip Intel on the price/performance scale, and they get enough market share out of it to fund healthy future development and maintain their role as a David to Intel's Goliath.
I could be wrong, but I'd be interested to hear why. --
I'll admit that why one person might pay $20M to spend a little while in Mir isn't entirely clear to me. But two people paying $40M would make perfect sense! --
"Secret sharing" allows you to break a piece of data (usually a secret key) into N "shares", such that you only need M %lt; N shares to reconstruct the secret, but such that you don't have sufficient information to reconstruct the secret with M-1 shares (ie it's not just impractical, it's information-theoretically impossible). This means you could extend the scheme to keep working even if one or more of the participating sites go offline.
However, I don't believe any such scheme will work. If it turns out that existing law is insufficient to prosecute participants, they'll extend the law so that acting in a way that could facilitate such a scheme is illegal, and that will include participating in FreeNet, Gnutella, the Eternity service, or whatever. That's why we need both the technology and the data havens. --
None of the AES "top five" have fallen to an attack, even a wholly impractical attack, that breaks all rounds of the cipher. All of them break if you reduce them to few enough rounds. I don't know why you name MARS as subject to these attacks in particular, though "MARS attacks!" is a great title for a paper; the two that look shakiest at the moment are RC6 and Rijndael (though note that all of the designers are still happy with their current designs).
Oh, and fast implementations of Serpent take up more FPGA area than you might expect - in fact, more than RC6, despite the multiply in RC6. This is because it makes sense to unroll the loops eight times to hit the "sweet spot". However, it's perfectly fast in software - not quite as blinding as the other AES candidates, but plenty fast enough, especially on architectures other than the register-poor x86.
MacGuffin was proposed by Matt Blaze and Bruce Schneier; it was never meant for serious use, but to encourage analysis of a new structure, the GUFN (generalised unbalanced Feistel network). --
This just isn't any kind of an advantage. All the gains that you list for having a slow key schedule can be gained with a few extra key bits. If you really can't get a few extra key bits for some reason, it's no problem to artifically slow the key schedule; just hash the key a few thousand times. With a construction like abreast Davis-Meyer, you can even use the block cipher to do the hashing. Fast keyschedules are a Good Thing and there's nothing to be said for deliberately slowing them down.
There may be resasons for choosing Blowfish rather than Twofish, but this isn't one of them. Actually, I think there are only three:
* you don't trust any cipher less than five years old
* you have to have a 64-bit block, despite the advantages of a 128-bit block
I agree 100% that Triple DES is a good algorithm to go for unless you have some reason not to. The main reason not to, of course, is performance; it's also a big, complex algorithm, so you don't want to try and implement it yourself. But if you don't need blistering performance out of your crypto, and you don't plan to implement the crypto yourself (the wise choice) then go for 3DES.
Freedom is *not* an issue with 3DES: you have all the same freedoms with it as you do with Blowfish. Blowfish's advantage over 3DES is substantially better performance in software, and greater simplicity. It's probably a good second choice for this sort of thing; it's pretty much the oldest standing unencumbered strong block cipher designed for speed in software, and thus among the most trustworthy.
Once the AES winner has been around awhile, this questions will be moot; everyone will use the AES for most applications that don't require some special other choice. The concensus at the last AES conference seemed to be that none of the AES candidates would be properly broken short of an extraordinary revolution in cryptanalysis that might leave none of today's ciphers standing; caveats apply to Rijndael (which some wanted extended to 18 rounds) and to RC6 (which just doesn't leave a lot of people with warm fuzzies on the security front).
Of course, the question arises whether it's a block cipher you really need at all. If you're doing bulk encryption, you need a stream cipher, and a block cipher in a chaining mode is just one way to build a stream cipher. Try asking a much more specific question on sci.crypt and see what advice you get. Normally the answer is that there's already a standard for what you're trying to do, and you're best off using what it mandates.
Ask me a more specific question and I'll try and give a more specific answer... --
OK, so it's a trojan that opens a port to listen for arbitrary instructions, and broadcasts the port it's listening on on an IRC channel. Does it authenticate the instructions it receives with public key crypto?
If not, what's to stop us listening on the channel as well, and connecting to each advertised IP address, sending instructions which deactivate the trojan? Raises interesting technical and ethical issues, but it seems to me like the ultimate in "white hat cracking"... --
That would be just wonderful! Stripped of the ability to break them up, the DOJ would be forced to resort to another measure.
Perhaps the "stake through the heart" remedy, which is my favourite: forcing the US company that remains to release all of its intellectual property to the public domain.
Then the tiny stump company that would survive in BC can do what the hell it likes... --
This, and lots of other sorts of spamming, admit only one really good solution: collaborative filtering. You can find out more about this from Berkeley's link farm. --
The hardware RNG is a much better source of entropy than any other source on your machine, including your Sound Blaster. You can just get more randomness from it in less time. I wish they'd allow access to the raw ouput so we could do a full assesment.
And the serial number *was* a Bad Thing. People change NIC etc too often to reliably track them through it, and *lots* of people won't have NICs at all. Processors are far more reliable for this job. And there's sort of an excuse for those serial numbers, whereas there was never a plausible excuse for the CPUID. --
Don't pay any heed to all those crowds of people saying they didn't like your design, it's nothing to do with your design. Remember all the similar flames Jakob Nielsen (who we "parrot") got when he was interviewed here?
...No?
...Funny that, I don't either.
Sorry, I think you'll find that the truth is the opposite of what you're trying to portray: Slashdotters like to cite Nielsen as an authority on how to do it right because we feel *he* speaks for *us*. We're not taking what he says on faith; most of it is things we've all said ourselves from time to time, and we're damn glad that there's at least one high-profile Web designer prepared to say it, and make a convincing case for it too.
Since your pages are personal, you're not obliged to make anyone like them, but personally I can't see the point of deliberately publishing something in a way that puts potential readers off. I know I reach straight for the "back" button when I see those cardinal sins. --
Well said! +1, Dead Right.
on
Boo No More
·
· Score: 2
Someone tell Jakob Nielsen, I think he has another test case. Next time I write to one of these firms saying "I can't be bothered to use your web site, fix it" I shall ask them if they want to be the next boo.com. --
Slashdot Mirror
PayPal has essentially none of the cool features considered desirable for a cryptographic cash protocol, so there's still plenty of room for competition based on better technology. Check out the Lucre home page for details of a (seemingly) patent-free system for providing untraceable electronic cash.
--
For all practical purposes, DES takes a 56-bit key. OK, so the standards specify that you have to have eight extra "parity" values but they're of no cryptographic value; it's not really accurate to refer to them as key bits, they're more like key padding bits.
A real 64-bit key is pretty hard to crack; the distributed efforts to crack 64-bit RC5 are still running and won't finish for some years yet.
I should also point out that the export controls have been relaxed considerably, and it now seems to be legal to export strong crypto like PGP from the USA...
--
Whether or not you distribute Qt, it's illegal to distribute KDE binaries because their dependency on Qt makes it a contravention of the GPL. Note that KDE includes some GPL code that was not explicitly contributed to the KDE project, so even if they wanted to add the extra permission needed to distribute KDE binaries they'd have to get the signatures of non-KDE developers to do it. IIRC, at least one developer whose GPL code is used in the project has indicated that he would *not* give such permission: L. Peter Deutsch, author of Ghostscript.
--
As far as I can tell, we're the most clueful PSP in the UK. I think we're the only ones to have done a proper re-implementation of the banking protocols, and our solutions are implemented using Perl running on Linux. Our client-side code is all open sourced using the X11 license, and we provide Perl, C, and Java implemetations for Unix and NT, as well as more than one shopping cart implementation. And we have some really cool stuff lined up, including eFalcon fraud detection and some other things I can't talk about just now.
My work address is what you might guess (the local part is "paul"), so feel free to mail me any questions, though where appropriate I reserve the right to pass them on to the enquiries address in London!
--
RMS isn't arguing that "the Open Source model isn't necessarily the best development model all of the time". RMS argues that free software is just *right*, and prohibiting sharing is, well, wrong. When people argue about these issues as if they are to be judged solely on their efficacy at producing software which doesn't suck, I understand better why RMS rejects the term "Open Source" altogether.
--
Combine these shoes with the Ursus Mark VI armoured suit, arrive in your personal helicopter... from Slashdot, I can get the tech I need to become a superhero! Now all I need are some nifty superhero-style weapons!
--
If I claim that I had a fight with Mike Tyson and he won, it's relatively unremarkable; the only implausible bit is that we might meet and fight in the first place, not that he wins. If I claim I had a fight with Mike Tyson and I won, such a claim is far less believable.
Thus, if your personal experience tells you that Linux kicks the shit out of MS operating systems for Web server performance, a benchmark test whose results accord with that experience is more believable than one which contradicts it.
That's just good sense, isn't it?
--
Reading the patent, these people clearly do have some familiarity with modern crypto. I still think most of this is bogus but "snake-oil merchants" and "no clue" is putting it a bit strongly.
--
NTRU are, as far as I can tell, snake-oil merchants with no clue about real crypto. If anyone can think of an advantage of encrypting a piece of music with lots of short keys over encrypting the entire thing with 256-bit Serpent in counter mode I'd be interested to hear it.
--
I believe the revolutionary technology you're describing has already been heralded by the Onion.
--
The point of the method is to make it easy to collect the information, while making it difficult to blame the publishers. Janet Reno is supposed to be able to read it; this is supposed to make it more difficult, legally speaking, to get the information offline. I don't think it'll work but it's not utterly mad. It's not exactly unobvious either.
Your sums are wrong for point 3 as well. If you want a chance on the order of 50%, you'll have to generate around 2^32 pads; that's more like billions than millions. I still think that's too small, but hey, move to a 160-bit identifier (perhaps the SHA-1 of the pad?) and you won't get collisions.
--
Crusoe's *peak* power consumption is less than half the *idle* power consumption of this new chip. That's a much larger advantage than a factor of two. Setting even that aside, the difference between three hours of battery life and six is pretty visible and important to customers.
By contrast, AMD seem to barely pip Intel on the price/performance scale, and they get enough market share out of it to fund healthy future development and maintain their role as a David to Intel's Goliath.
I could be wrong, but I'd be interested to hear why.
--
I'll admit that why one person might pay $20M to spend a little while in Mir isn't entirely clear to me. But two people paying $40M would make perfect sense!
--
"Secret sharing" allows you to break a piece of data (usually a secret key) into N "shares", such that you only need M %lt; N shares to reconstruct the secret, but such that you don't have sufficient information to reconstruct the secret with M-1 shares (ie it's not just impractical, it's information-theoretically impossible). This means you could extend the scheme to keep working even if one or more of the participating sites go offline.
However, I don't believe any such scheme will work. If it turns out that existing law is insufficient to prosecute participants, they'll extend the law so that acting in a way that could facilitate such a scheme is illegal, and that will include participating in FreeNet, Gnutella, the Eternity service, or whatever. That's why we need both the technology and the data havens.
--
None of the AES "top five" have fallen to an attack, even a wholly impractical attack, that breaks all rounds of the cipher. All of them break if you reduce them to few enough rounds. I don't know why you name MARS as subject to these attacks in particular, though "MARS attacks!" is a great title for a paper; the two that look shakiest at the moment are RC6 and Rijndael (though note that all of the designers are still happy with their current designs).
Oh, and fast implementations of Serpent take up more FPGA area than you might expect - in fact, more than RC6, despite the multiply in RC6. This is because it makes sense to unroll the loops eight times to hit the "sweet spot". However, it's perfectly fast in software - not quite as blinding as the other AES candidates, but plenty fast enough, especially on architectures other than the register-poor x86.
MacGuffin was proposed by Matt Blaze and Bruce Schneier; it was never meant for serious use, but to encourage analysis of a new structure, the GUFN (generalised unbalanced Feistel network).
--
This just isn't any kind of an advantage. All the gains that you list for having a slow key schedule can be gained with a few extra key bits. If you really can't get a few extra key bits for some reason, it's no problem to artifically slow the key schedule; just hash the key a few thousand times. With a construction like abreast Davis-Meyer, you can even use the block cipher to do the hashing. Fast keyschedules are a Good Thing and there's nothing to be said for deliberately slowing them down.
There may be resasons for choosing Blowfish rather than Twofish, but this isn't one of them. Actually, I think there are only three:
* you don't trust any cipher less than five years old
* you have to have a 64-bit block, despite the advantages of a 128-bit block
* you want something easier to code
--
I agree 100% that Triple DES is a good algorithm to go for unless you have some reason not to. The main reason not to, of course, is performance; it's also a big, complex algorithm, so you don't want to try and implement it yourself. But if you don't need blistering performance out of your crypto, and you don't plan to implement the crypto yourself (the wise choice) then go for 3DES.
Freedom is *not* an issue with 3DES: you have all the same freedoms with it as you do with Blowfish. Blowfish's advantage over 3DES is substantially better performance in software, and greater simplicity. It's probably a good second choice for this sort of thing; it's pretty much the oldest standing unencumbered strong block cipher designed for speed in software, and thus among the most trustworthy.
Once the AES winner has been around awhile, this questions will be moot; everyone will use the AES for most applications that don't require some special other choice. The concensus at the last AES conference seemed to be that none of the AES candidates would be properly broken short of an extraordinary revolution in cryptanalysis that might leave none of today's ciphers standing; caveats apply to Rijndael (which some wanted extended to 18 rounds) and to RC6 (which just doesn't leave a lot of people with warm fuzzies on the security front).
Of course, the question arises whether it's a block cipher you really need at all. If you're doing bulk encryption, you need a stream cipher, and a block cipher in a chaining mode is just one way to build a stream cipher. Try asking a much more specific question on sci.crypt and see what advice you get. Normally the answer is that there's already a standard for what you're trying to do, and you're best off using what it mandates.
Ask me a more specific question and I'll try and give a more specific answer...
--
OK, so it's a trojan that opens a port to listen for arbitrary instructions, and broadcasts the port it's listening on on an IRC channel. Does it authenticate the instructions it receives with public key crypto?
If not, what's to stop us listening on the channel as well, and connecting to each advertised IP address, sending instructions which deactivate the trojan? Raises interesting technical and ethical issues, but it seems to me like the ultimate in "white hat cracking"...
--
...to mail this to me as well as posting it here.
--
That would be just wonderful! Stripped of the ability to break them up, the DOJ would be forced to resort to another measure.
Perhaps the "stake through the heart" remedy, which is my favourite: forcing the US company that remains to release all of its intellectual property to the public domain.
Then the tiny stump company that would survive in BC can do what the hell it likes...
--
This, and lots of other sorts of spamming, admit only one really good solution: collaborative filtering. You can find out more about this from Berkeley's link farm.
--
The hardware RNG is a much better source of entropy than any other source on your machine, including your Sound Blaster. You can just get more randomness from it in less time. I wish they'd allow access to the raw ouput so we could do a full assesment.
And the serial number *was* a Bad Thing. People change NIC etc too often to reliably track them through it, and *lots* of people won't have NICs at all. Processors are far more reliable for this job. And there's sort of an excuse for those serial numbers, whereas there was never a plausible excuse for the CPUID.
--
Don't pay any heed to all those crowds of people saying they didn't like your design, it's nothing to do with your design. Remember all the similar flames Jakob Nielsen (who we "parrot") got when he was interviewed here?
...No?
...Funny that, I don't either.
Sorry, I think you'll find that the truth is the opposite of what you're trying to portray: Slashdotters like to cite Nielsen as an authority on how to do it right because we feel *he* speaks for *us*. We're not taking what he says on faith; most of it is things we've all said ourselves from time to time, and we're damn glad that there's at least one high-profile Web designer prepared to say it, and make a convincing case for it too.
Since your pages are personal, you're not obliged to make anyone like them, but personally I can't see the point of deliberately publishing something in a way that puts potential readers off. I know I reach straight for the "back" button when I see those cardinal sins.
--
Someone tell Jakob Nielsen, I think he has another test case. Next time I write to one of these firms saying "I can't be bothered to use your web site, fix it" I shall ask them if they want to be the next boo.com.
--
This story isn't about how Linux triumphed over Windows.
This story is about how CNN felt it worthwhile to report that, in this instance, Linux triumphed over Windows.
When most of the media just reported that the virus affected "computers", it's nice to see that people occasionally get this one right.
--