As others pointed out: QC will not kill off symmetric cryptography. It will also not kill off public key cryptography that is not based on number-theoretic assumptions. A good example is Lamport's one-time signature scheme, which combined with Merkle's authentication trees can yield workable digital signature schemes. The signatures tend to be a bit big (in the order of a few Kbytes for practical parameters, no big deal in this day and age). The public keys are small, one hash value, and validation is fast.
I don't know of anything that's nearly as convenient as RSA or DH for privacy/key exchange, except maybe Maurer's scheme where you need a satellite that transmits random bits to the world, and every receiver gets its own noisy copy.
I agree that sending a password to a server is always a risk. I don't think SRP is the only solution, other solutions have been published.
Key stretching is also not the only way to increase the workfactor for dictionary searches on passwords. See Str engthening passwords for another approach.
To get back to the original poster's problem: I'd introduct client-side certificates first (to keep random people from connecting to the server), and worry about SRP or cryptocards later.
You imprint with a secret key in addition to a MAC or network address. And then you run a protocol like AKEP2 to authenticate and set up session keys, for instance.
This is all pretty standard cryptography, and lightweight enough to put in a single-chip embedded system.
don't believe everything you read in/. The Israeli quantum cracker message is 100% bogus. Public-key crypto would be in trouble if a quantum computer of sufficient size turns out to be feasible, but symmetric crypto can just double the size of its keys and go on. A secure solution can and has been built using symmetric crypto alone.
Read it again. The 'imprint' lasts forever, unless you push the reset button in the battery compartment or some such. We're talking about _small_ devices here, stuff for which full-fledged public-key crypto is severe overkill.
A strong solution would be to build a Faraday cage and do the imprinting in it.
As usual, the "radical new ideas" were not that new. The separation of powers (Executive, Legislative, and Judicial) is straight from Montesquieu (Trias Politica), and democracy was not actually invented in the US either. The authors of the US constitution deserve credit for actually trying out all these ideas.
This is not about character assasination of NSA staff. This is about a governement agency refusing oversight by the elected representatives of the people, and the issue is whether this agency routinely violates the constitutional rights of the people.
Things can get interesting if you can lure them into trying an intrusion. Log _everything_, then call the FBI:-).
Re:Firewalling ICMP takes care of this, folks.
on
Linux 2.2 DoS Attack
·
· Score: 2
As others mentioned before: filtering ICMP wholesale is not the right thing to do. It breaks path MTU, redirects (if you need them), and attempts to connect to machines that are down take forever to time out, because you don't get any 'host unreachable' messages.
Firewalls are not the answer to these problems either. These bugs need to be fixed, dumb protocols need to be fixed or discarded, in stead of patching things up with kludges and afterthoughts like IPSEC, firewalls and the like.
It would be nice if people would start designing protocols with security in mind, in stead of trying to add it on afterward. Sorry about the rant.
mbox gripes: writing a program to access a mbox file securely is, let's say, non-trivial, especially when combined with NFS. It can be done, though, look in the procmail sources. The fun really starts when sendmail is using a different locking mechanism than your mail client....
I've found ">From" in books. What's the cause: the mbox format.
Then again: mbox is ancient, I don't think the author of binmail can be blamed for this.
The amount of cruft we've collected over the years sometimes scares me.
Re:RedHat should pay for an "independent" test
on
NOS Crossroads
·
· Score: 1
What about having different OS VARs/manufacturers slugging it out? Then the tests would be more fair. Let M$/RH/Sun/Novell set up their own systems and tune them. Let them build the best server for (say) $20K in hardware (total?) cost. Get a fiercely independent referee.
This may be the best thing that ever happened to bootleggers: Microsoft setting the standard. It's as likely to be secure as NT is, so I suspect that someone will be able to reverse-engineer it (which is probably illegal). If not, a virtualized soundcard driver will let you get at the data anyway.
In my experience a lot of coders are grunt-coders. They use the same techniques all the time, appropriate or not. Coders that actively try to keep up with new algorithms, theoretical work etc. are few and far between. The ones that do are most likely the ones with advanced degrees.
I don't consider half the things you have to do to get Linux (and other systems) installed real learning. Even after so many years of 'improvements' in PCs they're still technologically inferior to the Mac II I used 10 years ago, which could autoconfigure the bus without user intervention (PCI systems tend to have all devices share the same interrupt, and there's no autovector support). Writing XFree config files for instance should be considered a necessary evil, not an 'opportunity for learning'. Been there, done that, and if someone automates the process I don't have to do it again.
I have to agree that Applied Cryptography is a very good book, but it does not contain everything there is to know about writing safe crypto applications. The "Handbook of Applied Cryptography" is a more thorough treatise. For more specific stuff look on www.counterpane.com, they've got a huge online literature list.
This little macro virus shows one problem: current environments (OSs) do not have the facilities you'd need to implement really secure systems. Unless you want to run Trusted Solaris or similar. We need a safe place to store private keys, like a smartcard. Selecting a good passphrase is terribly difficult.
Slashdot Mirror
I don't think it's Scientology's beliefs that got the German federal and state governements all upset, it's their actions.
I don't know of anything that's nearly as convenient as RSA or DH for privacy/key exchange, except maybe Maurer's scheme where you need a satellite that transmits random bits to the world, and every receiver gets its own noisy copy.
Key stretching is also not the only way to increase the workfactor for dictionary searches on passwords. See Str engthening passwords for another approach.
To get back to the original poster's problem: I'd introduct client-side certificates first (to keep random people from connecting to the server), and worry about SRP or cryptocards later.
This is all pretty standard cryptography, and lightweight enough to put in a single-chip embedded system.
don't believe everything you read in /. The Israeli quantum cracker message is 100% bogus. Public-key crypto would be in trouble if a quantum computer of sufficient size turns out to be feasible, but symmetric crypto can just double the size of its keys and go on. A secure solution can and has been built using symmetric crypto alone.
Read it again. The 'imprint' lasts forever, unless you push the reset button in the battery compartment or some such. We're talking about _small_ devices here, stuff for which full-fledged public-key crypto is severe overkill.
A strong solution would be to build a Faraday cage and do the imprinting in it.
Singer's mother is presumably able to decide for herself, unlike a newborn child with, say, most of the brain missing.
As usual, the "radical new ideas" were not that new. The separation of powers (Executive, Legislative, and Judicial) is straight from Montesquieu (Trias Politica), and democracy was not actually invented in the US either. The authors of the US constitution deserve credit for actually trying out all these ideas.
This is not about character assasination of NSA staff. This is about a governement agency refusing oversight by the elected representatives of the people, and the issue is whether this agency routinely violates the constitutional rights of the people.
Things can get interesting if you can lure them into trying an intrusion. Log _everything_, then call the FBI :-).
Firewalls are not the answer to these problems either. These bugs need to be fixed, dumb protocols need to be fixed or discarded, in stead of patching things up with kludges and afterthoughts like IPSEC, firewalls and the like.
It would be nice if people would start designing protocols with security in mind, in stead of trying to add it on afterward.
Sorry about the rant.
They can just get an AOL account :-) (nsa1234@aol.com)
mbox gripes: writing a program to access a mbox file securely is, let's say, non-trivial, especially when combined with NFS. It can be done, though, look in the procmail sources. The fun really starts when sendmail is using a different locking mechanism than your mail client....
I've found ">From" in books. What's the cause: the mbox format.
Then again: mbox is ancient, I don't think the author of binmail can be blamed for this.
The amount of cruft we've collected over the years sometimes scares me.
What about having different OS VARs/manufacturers slugging it out? Then the tests would be more fair. Let M$/RH/Sun/Novell set up their own systems and tune them. Let them build the best server for (say) $20K in hardware (total?) cost. Get a fiercely independent referee.
Should make for some interesting reading.
The Chor-Rivest knapsack system fell to a lattice-reduction attack a while back.
Fraud involves misrepresentation. I don't see where RedHat is misrepresenting what it's selling or doing. Sounds like a bad case of sour grapes to me.
This may be the best thing that ever happened to bootleggers: Microsoft setting the standard. It's as likely to be secure as NT is, so I suspect that someone will be able to reverse-engineer it (which is probably illegal). If not, a virtualized soundcard driver will let you get at the data anyway.
{
if(n >= 8)
printoct(n / 8);
putchar("01234567"[n%8]);
}
So this is considered 'clever' these days. I think that anyone pretending to be a programmer should be able to come up with something this in no time.
Quiz # 2: make a routine that prints a number where the radix is an argument (2 = radix Quiz #3: don't use recursion
In my experience a lot of coders are grunt-coders. They use the same techniques all the time, appropriate or not. Coders that actively try to keep up with new algorithms, theoretical work etc. are few and far between. The ones that do are most likely the ones with advanced degrees.
I don't consider half the things you have to do to get Linux (and other systems) installed real learning. Even after so many years of 'improvements' in PCs they're still technologically inferior to the Mac II I used 10 years ago, which could autoconfigure the bus without user intervention (PCI systems tend to have all devices share the same interrupt, and there's no autovector support). Writing XFree config files for instance should be considered a necessary evil, not an 'opportunity for learning'. Been there, done that, and if someone automates the process I don't have to do it again.
I have to agree that Applied Cryptography is a very good book, but it does not contain everything there is to know about writing safe crypto applications. The "Handbook of Applied Cryptography" is a more thorough treatise. For more specific stuff look on www.counterpane.com, they've got a huge online literature list.
The sources are available all over the Internet.
This little macro virus shows one problem: current environments (OSs) do not have the facilities you'd need to implement really secure systems. Unless you want to run Trusted Solaris or similar. We need a safe place to store private keys, like a smartcard. Selecting a good passphrase is terribly difficult.