Re:Americans will buy anything "exotic"....
on
Slashdot's Vastu
·
· Score: 1
Here in London you can see people on the Tube reading books about how to improve their health and wealth through the power of prayer. It's a weird sort of magic for an unusual sort of Christian.
I'm thinking of the OVC proposal rather than yours. In that system the machine-readable marks are not the human-readable marks, but spot checks are used to ensure that the two are always consistent. However the main point - that the work that the tally machine does can be audited and therefore it need not be implicitly trusted - stands in either case.
I'm now wondering how computers can be used to ensure that ballot boxes reach the vote counters unmolested...
The scanning/counting machine would have to be absolutely auditable, as simple and as transparent as possible. Every aspect of its operation would be required to be public domain, and available to any citizen upon request.
Every part of the system needs to be maximally auditable. However, you seem to be implying that this is the only possible defence against corrupt scanning/counting machines, and I don't think that's so. Get the machine to count the votes in thousand-vote bundles; then select a few bundles at random, hand-count them, and check that it lines up with the machine count.
If the counts don't match, check that the barcode corresponds to the text on the ballot, to see if the fault is with the printing machine or the scanning/counting machine.
Among the bundles you check should be all the outliers by proportion of vote.
But then, so long as you don't redistribute the GPL grants you permission to do whatever you like anyway, so whether or not you've accepted it is moot.
Yes. In fact my sums tell me that a straight track half the radius in length could get the same final velocity for the same acceleration. Round track: v^2 = ar. Straight track: v^2 = 2lr.
There is no security reduction from RSA to factoring, for e=3 or any other e. In fact there's strong evidence that there will never be such a reduction.
In addition, any such security reduction won't apply to PKCS #1.5 - a proper padding method, like OAEP+, must be used for the security reduction to apply.
There is such a reduction for e=2 aka Rabin, but that's not RSA any more, because your equations have multiple solutions. I nonetheless recommend adoption of Rabin everywhere RSA is now used, since it's better in every possible respect.
A lion can only bite one person at a time. An attacker or a worm can attack many at once.
This is what breaks many intuitions about network security. People say "I have nothing worth taking, so no-one will attack my network". But as you surely know, unless suitably firewalled, a PC will come under attack within minutes of being put online, because each attacker attacks millions of machines at a time so attacks are cheap.
Actually such systems do exist, are surprisingly good, and getting better. They read a formal protocol specification in their own special language rather than source code, but they find real attacks that others have missed. I don't think they're ready to replace experts yet, but they're good enough to be used to find the things the experts missed.
You are wildly optimistic, I'm afraid
on
Crypto Snake Oil
·
· Score: 1
You know that's not how it is, right? In practice, if a hundred thousand people download it, then at most a thousand will hack on it, at most twenty or so will thoroughly review the security related code, and an average of zero of them will be cryptographers.
In the unlikely instance that a cryptographer does review it, they will suggest changes, and they'll be told to get lost; cf Gutmann trying to tell people to use proper padding with RSA, or my conversations elsewhere in this thread.
No, that doesn't characterize hash function security at all.
First of all, all hash functions of the same size are pretty much equally vulnerable to a brute force attack - that's practically the defining feature of a brute force attack. It's resistance to shortcut attacks that matters.
Secondly, there are loads of properties people want hash functions to have - not only preimage resistance but second preimage resistance, collision resistance, correlation-freedom, multiplication-freedom and more. In fact no-one has successfully formalized all the properties we want our hash functions to have: the formalism that comes closest to capturing it, the Random Oracle Model, is impossible for any instantiable hash function to achieve.
I stand corrected! Of course, they're making their case based on what's known in the public sphere rather than secret knowledge they can't allude to, but then they would, wouldn't they? Thanks for setting me straight on this.
Re:No, it's much harder than you think.
on
Crypto Snake Oil
·
· Score: 1
Actually your comment that I replied to gives me a fairly good idea of your current level of knowledge in crypto:-) It's sweet the way so many Slashdot users think that darkly hinting at an unspoken expertise will make us wonder if they are in fact Adi Shamir, but really, you give yourself away.
You illustrate my point - see some of the other comments I've replied to. CBC is hard to use correctly because the IVs have to be unpredictable to the attacker. CTR mode is generally a much better idea. Better yet, use EAX or GCM modes, which provide authentication as well as encryption. Frankly I'm sorry to hear that RFCs that propose using CBC mode with AES are being published; I know of no genuine advantage it offers over CTR mode. See
Re:two-pass is not an option...
on
Crypto Snake Oil
·
· Score: 1
Defensive much? If you really can't afford EAX - which you should check - look into using GCM mode; the authentication pass is pretty cheap there. Or if you can't afford that, and your AES accelerator is flexible enough, you could look at replacing the CTR mode with LEX to save even more on the encryption but using the GCM authenticator. Or if you tell me more about your situation: there may be a variety of other options. Authentication is very, very cheap - the theory of universal hashing allows us to cut it much closer to the bone than we can with encryption.
Or, you know, you could just deploy something with bad, broken crypto out of ignorance and advertise it as "Uses 128-bit AES for maximum security!" which seems to be your current plan and which was exactly what I was talking about when I first posted. You'll be following the example of thousands, it seems.
Re:why am I hand-rolling my crypto?
on
Crypto Snake Oil
·
· Score: 1
RC4 and RC5 are very different; all they have in common is a designer and a few ideas.
As the guy says, don't use CBC for authentication; that's broken. Since you have an AES accelerator EAX mode is probably a good fit; it provides both encryption and authentication.
You can do it wrong if you prefer, but it should be possible to do it right.
the NSA has been telling people for years now to not rely on RSA. They suggest switching over to Elliptic Curve or other advanced algorithm.
Provide a cite for that, please?
I don't personally feel very kindly disposed towards RSA - I don't see any advantage it has over Rabin-based schemes and important disadvantages - but I think it is scaremongering to say that the NSA have been warning people about it.
Re:No, it's much harder than you think.
on
Crypto Snake Oil
·
· Score: 1
Which books would you want to see on someone's bookshelf for you to consider respecting them?
Conference proceedings are a good sign, especially with your name on the contents page:-) Seriously, no book on the shelf can be a badge of expertise or otherwise, and I imagine most people who know what they're doing also have a copy of AC. It's just that there are a lot of people who consider themselves qualified to write cryptographic software because they've read it, and that just isn't so. If you're asking me to recommend a book, I've heard good things about Practical Cryptography.
IVs are public after encryption. However, in CBC mode an attacker must not be able to predict the IVs before encryption takes place. This is a pain; you're better off using CTR mode, for which your IVs need only be different from each other, and predictability is not a problem. Or better yet, EAX or GGM mode so you get authentication too. Why are you hand-rolling your crypto? Why did you use CBC rather than CTR mode? What are you using for authentication?
Your guess about what the IV is for is mistaken. For a simple example, think of what happens if you don't use an IV in a Vernam cipher (like RC4): this is trivially weak.
From what I can see, this checks only that what the product is using really is AES; it doesn't check that it's being used correctly or that the product is secure as a result.
Re:No, it's much harder than you think.
on
Crypto Snake Oil
·
· Score: 2, Informative
Er. To that specific question, I recommend using EAX or GGM modes, which are much easier to implement and to use correctly; they include authentication as well as encryption. However, to the more general point, the answer is to try to use existing crypto protocols rather than rolling your own wherever you can, and to get expert help if you can't. I haven't read it but I'm told Ferguson and Schneier's "Practical Cryptography" is aimed at people in your situation.
Slashdot Mirror
AES is typically under 20 cycles/byte.
Here in London you can see people on the Tube reading books about how to improve their health and wealth through the power of prayer. It's a weird sort of magic for an unusual sort of Christian.
> are we not men? Is a five O'clock shadow not acceptable at 5 O-friggin-clock?
Believe me, you care very much about getting a really good, close shave if you're a transvestite.
I'm thinking of the OVC proposal rather than yours. In that system the machine-readable marks are not the human-readable marks, but spot checks are used to ensure that the two are always consistent. However the main point - that the work that the tally machine does can be audited and therefore it need not be implicitly trusted - stands in either case.
I'm now wondering how computers can be used to ensure that ballot boxes reach the vote counters unmolested...
The scanning/counting machine would have to be absolutely auditable, as simple and as transparent as possible. Every aspect of its operation would be required to be public domain, and available to any citizen upon request.
Every part of the system needs to be maximally auditable. However, you seem to be implying that this is the only possible defence against corrupt scanning/counting machines, and I don't think that's so. Get the machine to count the votes in thousand-vote bundles; then select a few bundles at random, hand-count them, and check that it lines up with the machine count.
If the counts don't match, check that the barcode corresponds to the text on the ballot, to see if the fault is with the printing machine or the scanning/counting machine.
Among the bundles you check should be all the outliers by proportion of vote.
But then, so long as you don't redistribute the GPL grants you permission to do whatever you like anyway, so whether or not you've accepted it is moot.
I think they mean hysterical raisins.
Yes. In fact my sums tell me that a straight track half the radius in length could get the same final velocity for the same acceleration. Round track: v^2 = ar. Straight track: v^2 = 2lr.
There is no security reduction from RSA to factoring, for e=3 or any other e. In fact there's strong evidence that there will never be such a reduction.
In addition, any such security reduction won't apply to PKCS #1.5 - a proper padding method, like OAEP+, must be used for the security reduction to apply.
There is such a reduction for e=2 aka Rabin, but that's not RSA any more, because your equations have multiple solutions. I nonetheless recommend adoption of Rabin everywhere RSA is now used, since it's better in every possible respect.
If you find a fast, general solution (ie one that's polynomial time in the worst case) do let me know...
A lion can only bite one person at a time. An attacker or a worm can attack many at once.
This is what breaks many intuitions about network security. People say "I have nothing worth taking, so no-one will attack my network". But as you surely know, unless suitably firewalled, a PC will come under attack within minutes of being put online, because each attacker attacks millions of machines at a time so attacks are cheap.
Actually such systems do exist, are surprisingly good, and getting better. They read a formal protocol specification in their own special language rather than source code, but they find real attacks that others have missed. I don't think they're ready to replace experts yet, but they're good enough to be used to find the things the experts missed.
You know that's not how it is, right? In practice, if a hundred thousand people download it, then at most a thousand will hack on it, at most twenty or so will thoroughly review the security related code, and an average of zero of them will be cryptographers.
In the unlikely instance that a cryptographer does review it, they will suggest changes, and they'll be told to get lost; cf Gutmann trying to tell people to use proper padding with RSA, or my conversations elsewhere in this thread.
No, that doesn't characterize hash function security at all.
First of all, all hash functions of the same size are pretty much equally vulnerable to a brute force attack - that's practically the defining feature of a brute force attack. It's resistance to shortcut attacks that matters.
Secondly, there are loads of properties people want hash functions to have - not only preimage resistance but second preimage resistance, collision resistance, correlation-freedom, multiplication-freedom and more. In fact no-one has successfully formalized all the properties we want our hash functions to have: the formalism that comes closest to capturing it, the Random Oracle Model, is impossible for any instantiable hash function to achieve.
I stand corrected! Of course, they're making their case based on what's known in the public sphere rather than secret knowledge they can't allude to, but then they would, wouldn't they? Thanks for setting me straight on this.
Actually your comment that I replied to gives me a fairly good idea of your current level of knowledge in crypto :-) It's sweet the way so many Slashdot users think that darkly hinting at an unspoken expertise will make us wonder if they are in fact Adi Shamir, but really, you give yourself away.
It's worrying that you believe this. Even the worst snake oil is rarely so bad that a standard compressor can compress the output.
You illustrate my point - see some of the other comments I've replied to. CBC is hard to use correctly because the IVs have to be unpredictable to the attacker. CTR mode is generally a much better idea. Better yet, use EAX or GCM modes, which provide authentication as well as encryption. Frankly I'm sorry to hear that RFCs that propose using CBC mode with AES are being published; I know of no genuine advantage it offers over CTR mode. See
a pers/lipmaa-ctr.pdf
http://csrc.nist.gov/encryption/modes/workshop1/p
Defensive much? If you really can't afford EAX - which you should check - look into using GCM mode; the authentication pass is pretty cheap there. Or if you can't afford that, and your AES accelerator is flexible enough, you could look at replacing the CTR mode with LEX to save even more on the encryption but using the GCM authenticator. Or if you tell me more about your situation: there may be a variety of other options. Authentication is very, very cheap - the theory of universal hashing allows us to cut it much closer to the bone than we can with encryption.
Or, you know, you could just deploy something with bad, broken crypto out of ignorance and advertise it as "Uses 128-bit AES for maximum security!" which seems to be your current plan and which was exactly what I was talking about when I first posted. You'll be following the example of thousands, it seems.
RC4 and RC5 are very different; all they have in common is a designer and a few ideas.
As the guy says, don't use CBC for authentication; that's broken. Since you have an AES accelerator EAX mode is probably a good fit; it provides both encryption and authentication.
You can do it wrong if you prefer, but it should be possible to do it right.
the NSA has been telling people for years now to not rely on RSA. They suggest switching over to Elliptic Curve or other advanced algorithm.
Provide a cite for that, please?
I don't personally feel very kindly disposed towards RSA - I don't see any advantage it has over Rabin-based schemes and important disadvantages - but I think it is scaremongering to say that the NSA have been warning people about it.
Which books would you want to see on someone's bookshelf for you to consider respecting them?
:-) Seriously, no book on the shelf can be a badge of expertise or otherwise, and I imagine most people who know what they're doing also have a copy of AC. It's just that there are a lot of people who consider themselves qualified to write cryptographic software because they've read it, and that just isn't so. If you're asking me to recommend a book, I've heard good things about Practical Cryptography.
Conference proceedings are a good sign, especially with your name on the contents page
IVs are public after encryption. However, in CBC mode an attacker must not be able to predict the IVs before encryption takes place. This is a pain; you're better off using CTR mode, for which your IVs need only be different from each other, and predictability is not a problem. Or better yet, EAX or GGM mode so you get authentication too. Why are you hand-rolling your crypto? Why did you use CBC rather than CTR mode? What are you using for authentication?
Your guess about what the IV is for is mistaken. For a simple example, think of what happens if you don't use an IV in a Vernam cipher (like RC4): this is trivially weak.
From what I can see, this checks only that what the product is using really is AES; it doesn't check that it's being used correctly or that the product is secure as a result.
Er. To that specific question, I recommend using EAX or GGM modes, which are much easier to implement and to use correctly; they include authentication as well as encryption. However, to the more general point, the answer is to try to use existing crypto protocols rather than rolling your own wherever you can, and to get expert help if you can't. I haven't read it but I'm told Ferguson and Schneier's "Practical Cryptography" is aimed at people in your situation.