(I'm a relatively new Linux user and probably speak from a largely Windows background).
This FAQ looks a very good start....Writing a FAQ is extremely time consuming (I know, I've written the PGP DH vs PGP RSA FAQ) and this FAQ is a good foundation to build upon. It largely follows the content of the (also excellent....) book Maximum Linux Security by Anon.
Anyway, I'd like the FAQ to be expanded with:
GPG and PGP details
Details of 'On-The-Fly' disk encryption schemes (EFS, BestCrypt etc)
I don't see any reason that ACLs couldn't be implemented as a kernel feature that could be enabled or disabled when building the kernel. Sure, the hooks would have to be built into various parts of the kernel and may cause a little speed penalty, but I think the performance hit would be tiny.
If we're going to implement an ACL system for Linux, then we might as well make it MACL (mandatory access control) rather than the NT implementation of discresionary access control.
"Linux would start forking" - it's getting a bit boring hearing these kind of unjustifiable claims....
Rgds,
Sam
Your detail is fine, but to protect against malicious users, the GPS data needs to be signed by the "GPS server" [1] to prevent the user from simply changing the GPS location data to another value. In this instance and MD5 isn't sufficient: the user could simply substitute the MD5 for another known value.
Oh, the GPS data will also need to be timestamped - this prevents replay attacks.
[1]Either the data from the satelite could be signed in some way I guess, or the GPS decoder could be a "trusted host".
Over time AES will be incorporated into all security products and will become a defacto standard. We can already see that GnuPG includes full support and NAI/PGP is expected to follow shortly.
It's nothing that end users will have learn / know - it'll just be included as the standard. If someone wanted to send you an encrypted mail today then they'd still use PGP (or similar), you can't just take Rijndael and encrypt an e-mail (or web session, or SSH session or whatever).
Re:Recommend me a crypto book?
on
The Code Book
·
· Score: 2
You've indicated that you want a book that is "fun to read" and this in my mind leaves only one choice: Applied Cryptography 2nd Ed by B.Schneier. It's funny, well written, insightful and accessible.
Seriously, buy Applied Crypto...You won't regret it. Secrets & Lies is Schneiers follow-up and this is also a very good book, but is more into dealing with computer security rather than crypto.
What's bad: Codes and cyphers of importance in Britain and the United States dominate the book. There is almost no discussion of codes or codebreaking elsewhere.
True, but the Code Book doesn't claim to be a comprehensive treatment of cryptography through the ages and around the world...And for good reason: David Kahns The CodeBreakers is the definitive comprehensive and technically rich reference of cryptography in a historical context. My understanding is that The Code Book was supposed to be easy to read and accessible (like Dr Singhs other book "Fermats Last Theorem").
Personally I believe Singh achieves this - the book is very well written and "just at the right level" for a non-technical person to understand.
Hhhhm....Koblitz isn't bad, but is very terse and not nearly comprehensive. It's widely accepted that the current definitive work on cryptography is The Handbook of Applied Cryptography (HAC for short).
Literally every chapter of HAC is available on the HAC homepage here for free download in both.ps and.pdf format - so it's possible to "try before you buy".
The only area I'd say Koblitz has the upper hand is Elliptic Curves - HAC is very light on this topic.
This is the first time "normal" computer hardware has been used to break a 512-bit RSA key.
The first public break of an RSA key of this size was performed using 224 CPU hours on a Cray C916 whilst the team that cracked the codebook puzzles took just 13 days on a quad-Alpha Compaq beast.
Don't forget, before the export rules were changed around 90%+ of all "secure" SSL transactions on the internet were using 512-bit keys. Scary, huh?
Scramdisk is currently being ported from Windows 95/98/ME & NT/W2k to Linux (by myself and AJ). This will allow the creation of a "virtual container" that can contain any filesystem - including filesystems that implement journaling.
It's not clear from the post, but it would appear that Slashdot simply stores the username / passwords in a table unmangled?
Damn...The minimum you should have done is hashed it (with either MD5 or SHA-1 - both of these are available for Perl). The next (recommended) step is to also salt the password prior to hashing to prevent dictionary and similar attacks.
Bruce Schneier is right in Secret and Lies: people just keep making the same security mistakes time and time again:((((
It's great to see that the open source browsers can finally be used for "secure" use over the internet, but at the same time I'm wondering why they're using the now-public RSA encryption algorithm.
Because it's versatile, easy to implement and very well trusted. Oh, and it's free.
I'm not an encryption expert, but surely it seems to me that any algorithm that has been released by a company into the public domain cannot be particularly secure
Sorry, that's crap. The strength of RSA is built upon mathematics - how would a patent expiring change this in any way?
Still, we previously could have used a combination of Elgamal and DSS to do the same as RSA, but all of the existing web servers running SSL and cert vendors (Verisign et al) all solely use RSA - they don't offer Elgamal/DSS certs.
I'm going to direct this at Mr. Simpson as he seems to be greatly involved in this discussion.
I've been involved with PGP for years - I have no official involvement with NAI. More than happy to answer questions though:
In your opinion what is a good possible solution for this?
Apart from not introducing this devils-work "feature" in the first place?;)
Seriously, there may not be a nice answer. Erm, the first thing to do would be check every keyserver and let people know that they have ADKs. Secondly, release future versions with "Encrypt to ADK" off by default. Thirdly, change the protcol so that ADKs are part of the signed/hashed packet.
Is NAI likely to release a patch?
Probably. May be easier to fix v7 and offer free upgrades to this version for existing customers. This would allow you to easily identify users who are still using versions that are "vulnerable". I doubt they'll do this though - that would cut revenue:(
What about a new version which does not include the ADK feature? I can also see how this might be a desired feature for corporations who want to use the ADK's for thier intended use. Is it likely NAI would release a kludge in a vain attempt to keep this feature in the code?
Yes, they'll probably keep this feature. I think the last couple of bugs (including the v5 randomness bug) have done a lot of damage to PGP's reputation, which is very sad.
What is your opinion of NAI and do you think they'll do the "right" thing?
I have a lot of respect for Phil and Will Price. But this is a financial decision, we'll see. If they don't do the right thing, then I'll be sure to broadcast it from the rooftops!
Obviously with the growing popularity or PKI this can be seen as a good thing or a bad thing. Good in the fact that it exposes an inherent flaw in public key cryptography and might make some people seriously think about the implications of a public key infrastructure.
It's not a problem with public key crypto though, it'ts just an awful implementation!
Bad in the fact that a widely used version of PGP has a potentialy serious hole in it. I wonder how long the NSA has known about this one.
Should be fairly easy to see if someone has exploited the bug - just check all keys on the keyserver.
The problem is: Linux, BSD, Solaris, Be (IIRC) etc all have a/dev/random and/dev/urandom....NT doesn't export the same cryptographic strength RNG in the same way.
I agree - you are dependant on the strength of the Unix/dev/random - but most of the modern distributions seems to have been tried and tested.
Besides, who'd want to run an RNG you haven't seen the source of?!?!?
I wrote: GPG... uses the same ciphers (and more...) that NAI/PGP uses.
You wrote: No, it doesn't! PGP uses proprietary patented algorithms. GPG doesn't, never has and never will. THAT'S why it's superior to PGP.
PGP v5 onwards has implemented CAST & 3DES and DH/DSS as the asymmetric cipher - all non-proprietary. You may be refering to PGP v2.x - but that version doesn't suffer from these ADK problems and is thus totally unrelated to this current discussion...
I wrote: The only problem with GPG is that it should only be used under "proper" operating systems (e.g. any version of UNIX).
You wrote: NONSENSE! GPG is released under the GPL. You can port it to any operating system you want.
Have you ever used / installed GPG? If you read the documentation and source code is clear and obvious that GPG needs a decent source of randomness. GPG shouldn't be used on WIN32 for example because there is no suitable source of crypto strength randomness.
You wrote: Why don't you check your facts before posting to this site? Oh, I forgot, this is/. Never mind.
Coming from someone you clearly writes from a position of gross ignorance?
PS: Read my writings on GPG/PGP at: www.scramdisk.clara.net/pgpfaq.html if you doubt my credentials.
This is a hole, a bug, a failiure. It's easily countered by including ADK information in the hashed/signed portion of the key.
This discovery means that EVERY key on public key servers is potentially broken. Hell, any naive users key could have this ADK packet and not even be aware! Using "authorised" keys, whatever that means, isn't a solution.
This story isn't discussing the use/deployment of ADK, but rather that someone can add an ADK packet to any PGP key without corrupting the key or alerting the software: the ADK packet isn't covered by the hash function.
Key escrow good or bad is an interesting topic, but this story is about a damn big hole.
ADK has been a part of the NAI PGP implementation since v5 (e.g. 3 years ago).
There was a lot of arguing about including this feature, it's been documented in the user manual since v5, it's been talked about on newsgroups etc and it's been documented quite widely.
One saving grace is that the PGP standard (RFC2440) DOESN'T include this feature - so the problem should be fairly confined to users of NAI/PGP.
Again an example of Free OSS being better than the commerical alternatives?;)
I'm really surprised that anyone who follows PGP to any degree has failed to notice? Anyway, it's documented in my PGP DH vs PGP RSA FAQ at: http://www.scramdisk.clara.net/
Slashdot Mirror
(I'm a relatively new Linux user and probably speak from a largely Windows background).
This FAQ looks a very good start....Writing a FAQ is extremely time consuming (I know, I've written the PGP DH vs PGP RSA FAQ) and this FAQ is a good foundation to build upon. It largely follows the content of the (also excellent....) book Maximum Linux Security by Anon.
Anyway, I'd like the FAQ to be expanded with:
I don't see any reason that ACLs couldn't be implemented as a kernel feature that could be enabled or disabled when building the kernel. Sure, the hooks would have to be built into various parts of the kernel and may cause a little speed penalty, but I think the performance hit would be tiny.
If we're going to implement an ACL system for Linux, then we might as well make it MACL (mandatory access control) rather than the NT implementation of discresionary access control.
"Linux would start forking" - it's getting a bit boring hearing these kind of unjustifiable claims.... Rgds, Sam
Your detail is fine, but to protect against malicious users, the GPS data needs to be signed by the "GPS server" [1] to prevent the user from simply changing the GPS location data to another value. In this instance and MD5 isn't sufficient: the user could simply substitute the MD5 for another known value.
Oh, the GPS data will also need to be timestamped - this prevents replay attacks.
[1]Either the data from the satelite could be signed in some way I guess, or the GPS decoder could be a "trusted host".
3DES has always been entirely free of IP claims, so I don't see what's changed really?
Yeah, the interviewee was a little cold!
Over time AES will be incorporated into all security products and will become a defacto standard. We can already see that GnuPG includes full support and NAI/PGP is expected to follow shortly.
It's nothing that end users will have learn / know - it'll just be included as the standard. If someone wanted to send you an encrypted mail today then they'd still use PGP (or similar), you can't just take Rijndael and encrypt an e-mail (or web session, or SSH session or whatever).
You've indicated that you want a book that is "fun to read" and this in my mind leaves only one choice: Applied Cryptography 2nd Ed by B.Schneier. It's funny, well written, insightful and accessible.
Something like Handbook of Applied Cryptography is more precise and scientific in approach, but has 0% humour.
Seriously, buy Applied Crypto...You won't regret it. Secrets & Lies is Schneiers follow-up and this is also a very good book, but is more into dealing with computer security rather than crypto.
What's bad: Codes and cyphers of importance in Britain and the United States dominate the book. There is almost no discussion of codes or codebreaking elsewhere.
True, but the Code Book doesn't claim to be a comprehensive treatment of cryptography through the ages and around the world...And for good reason: David Kahns The CodeBreakers is the definitive comprehensive and technically rich reference of cryptography in a historical context. My understanding is that The Code Book was supposed to be easy to read and accessible (like Dr Singhs other book "Fermats Last Theorem").
Personally I believe Singh achieves this - the book is very well written and "just at the right level" for a non-technical person to understand.
Hhhhm....Koblitz isn't bad, but is very terse and not nearly comprehensive. It's widely accepted that the current definitive work on cryptography is The Handbook of Applied Cryptography (HAC for short).
Literally every chapter of HAC is available on the HAC homepage here for free download in both .ps and .pdf format - so it's possible to "try before you buy".
The only area I'd say Koblitz has the upper hand is Elliptic Curves - HAC is very light on this topic.
This is the first time "normal" computer hardware has been used to break a 512-bit RSA key.
The first public break of an RSA key of this size was performed using 224 CPU hours on a Cray C916 whilst the team that cracked the codebook puzzles took just 13 days on a quad-Alpha Compaq beast.
Don't forget, before the export rules were changed around 90%+ of all "secure" SSL transactions on the internet were using 512-bit keys. Scary, huh?
--
You say one thing, but mean your mother?
Scramdisk is currently being ported from Windows 95/98/ME & NT/W2k to Linux (by myself and AJ). This will allow the creation of a "virtual container" that can contain any filesystem - including filesystems that implement journaling.
Seriously, nobody that lives in the UK would ever claim that "Hawking fears that the atmosphere will become hotter".
It's cold in the UK. Damn cold in fact.
Erm, that's all......
It's not clear from the post, but it would appear that Slashdot simply stores the username / passwords in a table unmangled?
Damn...The minimum you should have done is hashed it (with either MD5 or SHA-1 - both of these are available for Perl). The next (recommended) step is to also salt the password prior to hashing to prevent dictionary and similar attacks.
Bruce Schneier is right in Secret and Lies: people just keep making the same security mistakes time and time again :((((
RSA released the patent to public domain 2 weeks ago.
It's great to see that the open source browsers can finally be used for "secure" use over the internet, but at the same time I'm wondering why they're using the now-public RSA encryption algorithm.
Because it's versatile, easy to implement and very well trusted. Oh, and it's free.
I'm not an encryption expert, but surely it seems to me that any algorithm that has been released by a company into the public domain cannot be particularly secure
Sorry, that's crap. The strength of RSA is built upon mathematics - how would a patent expiring change this in any way?
Still, we previously could have used a combination of Elgamal and DSS to do the same as RSA, but all of the existing web servers running SSL and cert vendors (Verisign et al) all solely use RSA - they don't offer Elgamal/DSS certs.
No it doesn't GPG ignores packet 10 - it doesn't know how to encrypt to ADK's!
GPG keys are vulnerable, but only when being encrypted to by NAI PGP implementations.......
I'm going to direct this at Mr. Simpson as he seems to be greatly involved in this discussion. I've been involved with PGP for years - I have no official involvement with NAI. More than happy to answer questions though:
In your opinion what is a good possible solution for this?
Apart from not introducing this devils-work "feature" in the first place? ;)
Seriously, there may not be a nice answer. Erm, the first thing to do would be check every keyserver and let people know that they have ADKs. Secondly, release future versions with "Encrypt to ADK" off by default. Thirdly, change the protcol so that ADKs are part of the signed/hashed packet.
Is NAI likely to release a patch?
Probably. May be easier to fix v7 and offer free upgrades to this version for existing customers. This would allow you to easily identify users who are still using versions that are "vulnerable". I doubt they'll do this though - that would cut revenue :(
What about a new version which does not include the ADK feature? I can also see how this might be a desired feature for corporations who want to use the ADK's for thier intended use. Is it likely NAI would release a kludge in a vain attempt to keep this feature in the code?
Yes, they'll probably keep this feature. I think the last couple of bugs (including the v5 randomness bug) have done a lot of damage to PGP's reputation, which is very sad.
What is your opinion of NAI and do you think they'll do the "right" thing?
I have a lot of respect for Phil and Will Price. But this is a financial decision, we'll see. If they don't do the right thing, then I'll be sure to broadcast it from the rooftops!
Obviously with the growing popularity or PKI this can be seen as a good thing or a bad thing. Good in the fact that it exposes an inherent flaw in public key cryptography and might make some people seriously think about the implications of a public key infrastructure.
It's not a problem with public key crypto though, it'ts just an awful implementation!
Bad in the fact that a widely used version of PGP has a potentialy serious hole in it. I wonder how long the NSA has known about this one.
Should be fairly easy to see if someone has exploited the bug - just check all keys on the keyserver.
I suppose I had better update my PGP FAQ now!
Cheers, Sam
The problem is: Linux, BSD, Solaris, Be (IIRC) etc all have a /dev/random and /dev/urandom....NT doesn't export the same cryptographic strength RNG in the same way.
I agree - you are dependant on the strength of the Unix /dev/random - but most of the modern distributions seems to have been tried and tested.
Besides, who'd want to run an RNG you haven't seen the source of?!?!?
Bzzzzzzt. Wrong. PGP is open source. See for example www.pgpi.com and download your own copy..........
Phew, someone else can RTFM ;)
I wrote: GPG ... uses the same ciphers (and more...) that NAI/PGP uses.
You wrote: No, it doesn't! PGP uses proprietary patented algorithms. GPG doesn't, never has and never will. THAT'S why it's superior to PGP.
PGP v5 onwards has implemented CAST & 3DES and DH/DSS as the asymmetric cipher - all non-proprietary. You may be refering to PGP v2.x - but that version doesn't suffer from these ADK problems and is thus totally unrelated to this current discussion...
I wrote: The only problem with GPG is that it should only be used under "proper" operating systems (e.g. any version of UNIX).
You wrote: NONSENSE! GPG is released under the GPL. You can port it to any operating system you want.
Have you ever used / installed GPG? If you read the documentation and source code is clear and obvious that GPG needs a decent source of randomness. GPG shouldn't be used on WIN32 for example because there is no suitable source of crypto strength randomness.
You wrote: Why don't you check your facts before posting to this site? Oh, I forgot, this is /. Never mind.
Coming from someone you clearly writes from a position of gross ignorance?
PS: Read my writings on GPG/PGP at: www.scramdisk.clara.net/pgpfaq.html if you doubt my credentials.
ARRGH! Wrong!
This is a hole, a bug, a failiure. It's easily countered by including ADK information in the hashed/signed portion of the key.
This discovery means that EVERY key on public key servers is potentially broken. Hell, any naive users key could have this ADK packet and not even be aware! Using "authorised" keys, whatever that means, isn't a solution.
BUZZZ...You're plain wrong I'm afraid.
This story isn't discussing the use/deployment of ADK, but rather that someone can add an ADK packet to any PGP key without corrupting the key or alerting the software: the ADK packet isn't covered by the hash function.
Key escrow good or bad is an interesting topic, but this story is about a damn big hole.
ADK has been a part of the NAI PGP implementation since v5 (e.g. 3 years ago).
There was a lot of arguing about including this feature, it's been documented in the user manual since v5, it's been talked about on newsgroups etc and it's been documented quite widely.
One saving grace is that the PGP standard (RFC2440) DOESN'T include this feature - so the problem should be fairly confined to users of NAI/PGP.
Again an example of Free OSS being better than the commerical alternatives? ;)
I'm really surprised that anyone who follows PGP to any degree has failed to notice? Anyway, it's documented in my PGP DH vs PGP RSA FAQ at: http://www.scramdisk.clara.net/
Rgds,
Sam