No, it's much harder than you think.
on
Crypto Snake Oil
·
· Score: 4, Insightful
If you believe that, no wonder so much insecure stuff is being written. I have been called upon to review code written by developers with your level of knowledge in crypto. They do things like use RSA without proper padding, or use predictable IVs in CBC mode, or fail to properly authenticate the message. They also add totally unnecessary complexity to the system in the mistaken belief that their improvements make it more secure. I shudder when I see a copy of "Applied Cryptography" on the shelves because it is just enough knowledge to be dangerous.
Even the experts make errors in cryptographic protocol design and implementation - I've been doing this for ten years and I've made at least one howler myself. Why do you think, contrary to the advice of pretty much everyone who really knows their stuff, that people with a couple of week's worth of knowledge can get this stuff right?
Snake oil that uses AES
on
Crypto Snake Oil
·
· Score: 4, Insightful
Many Slashdot readers are savvy enough to know that when a software product advertises itself as using, say, secret encryption algorithms with 10,000 bit keys, it's probably snake oil. But I'm seeing increasing amounts of snake oil that uses the Advanced Encryption Standard, AES, and it can be just as weak.
AES itself of course is nigh-on as trustworthy a cryptographic primitive of its kind that we have. But just because you've used the right primitive, doesn't mean you've built a secure product. You have to consider what chaining mode to use, how to handle passphrases if they exist, how to keep your secrets secret, defense against side channel attacks, and more.
What I look for is a product that provides enough information that I can actually assess its security - what attacks they've considered and how they've built the product to defend against them. What I see disturbingly often is a bald declaration that the product is secure, because it uses AES.
See "Parallel Collision Search with Cryptanalytic Applications" by Michael Weiner and Paul C Van Oorschot - you can get away with far less storage by iterating the key -> ciphertext map.
I can very cheaply write a program which has no false positives, and almost as cheaply one that has no false negatives; the first will run in constant time, while the second is linear in the size of the program:-)
I think you're better off erring on the side of explicitly listing domains that should be delegation-only - I'm sure de and museum aren't the only exceptions, but currently Cameroon are the only ones with an evil wildcard record that I know of.
When I poured coffee into the screen of my laptop, I did a fairly comprehensive search, and ended up buying the exact laptop one of my girlfriends already had. I think our criteria were pretty similar!
Biham and Seberry's "Py" can clip along at approaching 2 cycles/byte. That means a high-spec machine could be decrypting that 30GB file in around ten seconds - far faster than it can read it from disk, in fact.
There's no room to hide a secret "back door" in AES. Every step of its design is clear and well justified. There are no special hidden tables to sneak a back door into. And the guys who invented it were Belgian.
The NSA gave their blessing to all five final candidates. It's wildly implausble that they can break them all.
As another comment mentioned, it was IBM who first invented DC. And DES is vulnerable to linear cryptanalysis, indicating that maybe that's something that got invented in the open community first.
I don't believe that they are way ahead of us these days. They invented SHA-1 - now we've broken it. Skipjack's margin of safety has been whittled down to nothing with Biham's "impossible differentials". Their proposal "double counter mode" was broken within 24 hours. I think the widespread idea that they are still decades ahead of us is pure myth.
Looks good to me. I'd just like to emphasize one thing: don't try to get into crypto by inventing symmetric primitives. Try to get into it by breaking them. There's bound to be lots of cryptanalysis yet to be done on the eStream candidates, for example - I'm sure there's room for newcomers to crypto to make breakthroughs there.
I find that I sometimes hit backspace even when I'm not looking at the screen. I *know* I've made a mistake and correct it without breaking the flow of my typing.
That said, I might have a go at making the backspace key make a noise, so I have an incentive not to use it, and see what effect that has on my typing speed.
We have footage of police wandering around, and footage of cameras with plastic bags over them. Why no footage of a policeman putting a bag over a camera? In this country, CCTV cameras are mostly arranged so that if you try to disable one, you'll be caught on camera doing it by another.
I really want a still image of a policeman putting a bag over a camera that I can distribute far and wide.
It's barely a change at all. Some of the entrants were really innovative, cleaning up a lot of junk and providing a very immediate interface. When you compare to entries like these, you wonder why they bothered.
The cheapest TV I can find in the UK with an output resolution greater than 1366x768 (ie better than 720p, good enough for 1080i) was GB 964. Others are marketed as "supporting 1080i" which means that they can downsample..
Mozex is a great boon to Wikipedia editors. Load the entry in a real editor, then you'll have not only search but replace and other such nice features.
I'd love to hear some examples. It would be nice to see an example where something that's easy in a monolithic kernel is difficult in a microkernel. See, I imagine this bunch of distinct services all happily calling each other for what they need; I'd like to know more about how the need for complex distributed algorithms arises.
Heh:-) Sadly, the standard definitions of intractability don't allow anything like this - if the proof exists, a short program that immediately prints the proof out also exists.
The same problem affects formal definitions of "collision resistance" in hash functions. All hash functions have collisions, and therefore for any hash function there exists a very simple short program that prints out the collision. The fact that for SHA-512 we don't know how to write that program doesn't mean that it doesn't exist - it definitely does. To get around this, we speak of collision resistance for families of hash functions.
Slashdot Mirror
If you believe that, no wonder so much insecure stuff is being written. I have been called upon to review code written by developers with your level of knowledge in crypto. They do things like use RSA without proper padding, or use predictable IVs in CBC mode, or fail to properly authenticate the message. They also add totally unnecessary complexity to the system in the mistaken belief that their improvements make it more secure. I shudder when I see a copy of "Applied Cryptography" on the shelves because it is just enough knowledge to be dangerous.
Even the experts make errors in cryptographic protocol design and implementation - I've been doing this for ten years and I've made at least one howler myself. Why do you think, contrary to the advice of pretty much everyone who really knows their stuff, that people with a couple of week's worth of knowledge can get this stuff right?
Many Slashdot readers are savvy enough to know that when a software product advertises itself as using, say, secret encryption algorithms with 10,000 bit keys, it's probably snake oil. But I'm seeing increasing amounts of snake oil that uses the Advanced Encryption Standard, AES, and it can be just as weak.
AES itself of course is nigh-on as trustworthy a cryptographic primitive of its kind that we have. But just because you've used the right primitive, doesn't mean you've built a secure product. You have to consider what chaining mode to use, how to handle passphrases if they exist, how to keep your secrets secret, defense against side channel attacks, and more.
What I look for is a product that provides enough information that I can actually assess its security - what attacks they've considered and how they've built the product to defend against them. What I see disturbingly often is a bald declaration that the product is secure, because it uses AES.
Point taken. However, for meaningful figures, you should consider space cost too.
See "Parallel Collision Search with Cryptanalytic Applications" by Michael Weiner and Paul C Van Oorschot - you can get away with far less storage by iterating the key -> ciphertext map.
I can very cheaply write a program which has no false positives, and almost as cheaply one that has no false negatives; the first will run in constant time, while the second is linear in the size of the program :-)
A cellphone can't generate high enough frequencies or sufficiently pure tones to take advantage of the Mosquito effect.
I think you're better off erring on the side of explicitly listing domains that should be delegation-only - I'm sure de and museum aren't the only exceptions, but currently Cameroon are the only ones with an evil wildcard record that I know of.
n ly.php
zone "cm" { type delegation-only; }
http://www.isc.org/index.pl?/sw/bind/delegation-o
This is just so much sexist shit.
When I poured coffee into the screen of my laptop, I did a fairly comprehensive search, and ended up buying the exact laptop one of my girlfriends already had. I think our criteria were pretty similar!
I love having control over my life and my personal space.
I love being able to stay calm when things are stressful.
I love having the personal resources to really help my friends.
I love being able to buy ice-cream when I feel like it.
And there's nothing stopping me from playing Pooh sticks if I feel like it!
Probably someone told it "this sentence is false" or asked it "why?" or something, and that set off the fireworks in the case.
Biham and Seberry's "Py" can clip along at approaching 2 cycles/byte. That means a high-spec machine could be decrypting that 30GB file in around ten seconds - far faster than it can read it from disk, in fact.
There's no room to hide a secret "back door" in AES. Every step of its design is clear and well justified. There are no special hidden tables to sneak a back door into. And the guys who invented it were Belgian.
The NSA gave their blessing to all five final candidates. It's wildly implausble that they can break them all.
As another comment mentioned, it was IBM who first invented DC. And DES is vulnerable to linear cryptanalysis, indicating that maybe that's something that got invented in the open community first.
I don't believe that they are way ahead of us these days. They invented SHA-1 - now we've broken it. Skipjack's margin of safety has been whittled down to nothing with Biham's "impossible differentials". Their proposal "double counter mode" was broken within 24 hours. I think the widespread idea that they are still decades ahead of us is pure myth.
Looks good to me. I'd just like to emphasize one thing: don't try to get into crypto by inventing symmetric primitives. Try to get into it by breaking them. There's bound to be lots of cryptanalysis yet to be done on the eStream candidates, for example - I'm sure there's room for newcomers to crypto to make breakthroughs there.
Those high-end presses mostly don't run the Adobe RIP; last I looked, they ran the Harlequin RIP. And that RIP will soon support XPS:
http://www.globalgraphics.com/xps/
Full disclosure: I used to work on the core RIP team on the Harlequin RIP.
I find that I sometimes hit backspace even when I'm not looking at the screen. I *know* I've made a mistake and correct it without breaking the flow of my typing.
That said, I might have a go at making the backspace key make a noise, so I have an incentive not to use it, and see what effect that has on my typing speed.
We have footage of police wandering around, and footage of cameras with plastic bags over them. Why no footage of a policeman putting a bag over a camera? In this country, CCTV cameras are mostly arranged so that if you try to disable one, you'll be caught on camera doing it by another.
I really want a still image of a policeman putting a bag over a camera that I can distribute far and wide.
It's barely a change at all. Some of the entrants were really innovative, cleaning up a lot of junk and providing a very immediate interface. When you compare to entries like these, you wonder why they bothered.
http://skazani.pl/lukasz/projekty/slashdot/
http://insitemotion.com/slashdot2/
(no, I didn't enter either)
The cheapest TV I can find in the UK with an output resolution greater than 1366x768 (ie better than 720p, good enough for 1080i) was GB 964. Others are marketed as "supporting 1080i" which means that they can downsample..
Mozex is a great boon to Wikipedia editors. Load the entry in a real editor, then you'll have not only search but replace and other such nice features.
For a basic sex game aimed only at heterosexuals, anyway.
In a world where men never pretend to be women online and vice versa.
Now I want a design that combines the best of both.
Glad to know I'm not the only one in the dark :-) hopefully someone will be able to give an example that enlightens us both!
IANAKH (I am not a kernel hacker)
I'd love to hear some examples. It would be nice to see an example where something that's easy in a monolithic kernel is difficult in a microkernel. See, I imagine this bunch of distinct services all happily calling each other for what they need; I'd like to know more about how the need for complex distributed algorithms arises.
Heh :-) Sadly, the standard definitions of intractability don't allow anything like this - if the proof exists, a short program that immediately prints the proof out also exists.
The same problem affects formal definitions of "collision resistance" in hash functions. All hash functions have collisions, and therefore for any hash function there exists a very simple short program that prints out the collision. The fact that for SHA-512 we don't know how to write that program doesn't mean that it doesn't exist - it definitely does. To get around this, we speak of collision resistance for families of hash functions.