A worry about Prescott is that it's supporting all the Trusted Platform felgercarb that's been in the news recently. Cryptonomicon.Net has a few links to related web sites and opinions in the article: Intel Debuts Prescott.
I'm not sure I understand what you mean by "practical." I found all of them to have very good things to say about practical implementations. If you're just looking for source code, then no, they don't offer source code. If you're looking to implement a crypto algorithm for use in a real system, I wouldn't try to do it without them. The commentary at the end of each chapter in HAC is somewhat scattered and haphazard, Koblitz' books present a lot of this information in a structured way.
Applied Crypto is certainly a quality, wide-ranging tome on crypto. For years though, there have been a couple very good books with more implementation details. The Handbook of Applied Crypto from Menezes, et al comes immediately to mind. Either of the two books by Neal Koblitz are excellent. I also like to recommend Decrypted Secrets from Bauer. The Handbook of Applied Crypto is available as a free download from the author's site:
Larry Cohen over at Cryptonomicon.Net has published this story questioning the commonly accepted belief that Theo de Raadt had his DARPA funding pulled because of Anti-War comments. The story makes the interesting point that SELinux and TrustedBSD are home-grown projects, while OpenBSD (and de Raadt himself) are more international. Mr. Cohen also mentions that FreeBSD is "more mainstream," which I guess means that it has more mainstream users. I guess it's a good point that we haven't hear comment from DARPA or from Jonathan Smith at the University of Pennsylvania. This leads to the question, is all this anti-war / free-speech hubbub just sour grapes?
This is a very valid point. A number of us like to kvetch about Microsoft deploying IE in a non-secure default configuration, we should probably ask the same question of open source developers. I think there are three issues here: what the OpenSSL team is doing, what the disto developers are doing, and what application developers are doing.
The OpenSSL guys are writing the source code for a crypto library that can actually be made to be secure by default against timing attacks. This is, however, not the default configuration. So, because it's not the default configuration, the distro people grab the source, compile it with more or less the default options and move on. Application developers use crypto and ssl services from libcrypto or libssl and sort of "just expect it to work."
Part of the problem is that the level of understanding of these issues is rather limited within the latter two groups listed above. I'm not saying they're morons. Far from it. But they're not crypto specialists, and there's documentation out there that will actually tell you that if you're using CRT, you're not succeptible to timing attacks. So, If you're not attending the conferences and hearing about advances on some of these types of attacks, you might not know that you would want to turn on blinding by default.
Actually, if you look at the Cryptonomicon.Net article about this attack, you can see that, in fact, blinding has been added to the OpenSSL code. The issue is whether or not it is turned on by developers.
Congratulations, you've found a reference to a completely different attack.
This is a relatively well known type of attack. You ask a private key holder to decrypt a bunch of things and ask it how long it took. To defend against these types of attacks, the private key holder can either a) decrypt only a few things for you (which is a bit anti-social if you're an SSL engine.) or b) lie to you about how long it took to decrypt the things you sent.
The second option is effectively what happens when blinding is turned on.
In addition to the comments on using XP to solve all your problems, you may want to consider searching the internet for:
SCRUM and AGILE - SCRUM is an agile development methodology that keeps release time constant and removes functionality as deadlines approach.
Genetic-Algorithm and John-McGrew - John presented a report last year to BayCHI about usign a "genetic" algorithm to get his customers to QUICKLY converge on a user interface for a project on which he was working. I know you're not doing a UI per se, but the technique could be replicated to get your customer to help you find the critical functional components.
30 years? 1950 DA is supposed to swing by real close (or hit) in about 878 years, and I'm seriously frightened that we won't be able to get consensus in time to blast (or nudge) it out of it's orbit.
Yeah, but you can't use GPRS in the U.S. I was looking at upgrading my Cingular account to use GPRS until I noticed this handspring support page indicating that you can't upgrade yet.
I have since ditched my Treo and am eagerly awaiting a Sidekick.
On point number 1, you are absolutely, positively, 100% incorrect. The purpose of a certificate is not to establish that a SSL server operator is a "trustworthy business," it is to assert that a server operator has agreed to a set of behviors that will protect their private key, to provide an indemnification structure, and (optionally) verify that some trusted third party thinks you have a real address that can be served with legal papers should you not properly protect your private key.
To establish that a business is "trustworthy" is an entirely different proposition usually involving accountants, business consultants, and statisticians to evaluate the survey results from their customers. If someone is trying to tell you that a business will adhere to any agreement made with you simply because they are in posession of a valid SSL cert, they are blowing smoke up your kilt.
Also, I'm surprised that you would say that there is no cost associated with issuing a certificate. I'm sure that you administer multiple redundant secure Unix systems for fun, but most people actually have to get paid to do this work.
Just as a comment here... There's a reason it's not unreasonable to pay for certification that's not being mentioned here. The whole idea behind using a cert is to establish assurance in the identity of the ssl server. This identity assurance is established by the server proving posession of a private key related to a public key which has been certified by a certification authority. The certification authority uses a process supposedly outlined in their Certification Practice Statement to establish the identity of the ssl server. The CA itself has a certificate, certifying the identity of the person who owns the public key related to the private key that digitally signed the ssl server's certificate... it's the CA's self signed certificate! (yes, I'm ignoring the fact that some certificate chains have intermediate CAs, but that's for the advanced example.) Self signed certs are "bearer instruments" in a sense. If an adversary could get their self signed cert into your copy of Netscape or IE, then presumably they could start issuing bogus certs to inappropriate parties, and the whole chain of trust thing would go up in flames. To avoid this problem manufacturers of browsers, acting on behalf of their users (the relying parties) take special precautions to use root certs that have been verified to have really come from root CA's.
What you're paying for are the business operation costs to maintain the certificate issuing system and the indemnification costs.
So... you're probably wondering why you should care about all this when you're dealing with in internal site. Well... to a certain degree, you don't have to. This sort of trust chain is more useful in an environment where the two parties taking part in the communication have never met, nor have any of their "superiors" met. In a corporate environment, hierarchical organizations are common, and if you're dealing with a relatively large organization (say >300 people) it might be worth your while to investigate the idea of an internal CA.
WRT browsers, many corporate IT departments will devise a custom install for machines under their administrative control (you know, like a stock build of Win2k that gets ghosted onto new machines.) If this is the case in your organization, then it is (or at least it was) a relatively simple operation to install a new default root certificate into IE or Netscape (though I must admit, I've only done this myself with NS 4.something.)
As for CA software, if the only thing you're looking to do is create an internal root certificate that can be used to create certificates for internal ssl sites, OpenSSL will do this fine. Keon, Entrust, etc., etc. are generally justified when you want to start issuing client certs and establishing directories of internal certs & crls and revoking things...
uh... Who told you that DTDs and Schemas are not freely, openly, distributed? There is absolutely nothing I've seen that prevents you from downloading DTDs and/or Schemas. The documents defining XML, DTDs, and even Schemas are freely available (even though the Schema definition has gone through a great number of revisions, so it's sometimes hard to tell if you're using the right revision.)
Your second point seems to be a critique of encryption, not XML. Encryption is a fundamental technology for business, government, and personal information assurance. Think of XML as sort of ASCII meets the OSI presentation layer. If you start digging in the OSI protocols, you'll find reference to OIDs (Object Identifiers.) These things pop up everywhere, from SNMP traps to x.509 certificates. One thing you'll notice about OIDs is that some of them are well defined, and others are "internal use only." This has not led to protocols using OIDs being insecure or unuseful. DTDs and Schemas are in many ways the XML equivalent to OIDs. There will be a whole bunch of DTDs that are internal use only, but there's nothing wrong with this. OIDs that people tend to use in the real world are the ones about which we can find public documentation. DTDs and Schemas, I expect, will be the same way.
In defense of XML Information Assurance applications, I must say that the structured nature of XML allows applications to have a more refined model as to what in an XML document is encrypted, signed, decrypted, verified, hashed, and logged. If you've ever had to deal with ASN.1 and BER encoding, then you would know how wonderful XML is.
The rumor is that there was some sort of verbage about this in earlier drafts, but was removed at the behest of the software development community. I have been a TCF system developer for about 12 years now, and have always been depressed by the level of support for security features included in most consumer software.
However, NIST and NSA are starting to make some headway with the NIAP and other initiatives. At some point we'll probably need a security feature checklist and evaluation manual... Something much more detailed than what is found in the CC, and certainly more than what will ever be included in the NSSC.
Actually, it's not signed, sealed, and delivered just yet. There's a lot more input from govt. contractors coming in. While that may sound like a far cry from an "open process," many of the contractors are guys who worked on the early (D)ARPA internetworking projects.
Another thing to consider is that everything in the strategy for the private sector is optional. Rumor is that there was verbage in the strategy that would had "required" ISPs to distribute packet filtering firewall software to subscribers. That was taken out when Earthlink complained. So... if you ask me, it's not really a document to tell or mandate action from the general public. It looks more like a document that describes what the feds are going to do WRT information assurance on the net, and they want to go around and "raise awareness" in the program.
I will be interested to see what sort of spin gets put on these IA and data security in these town hall meetings. Will it be "Hey, this is what your government is doing, aren't we clever." or is it going to be "Hey, this is what we're doing, but all you peons are going to muck it up; you should let us legislate security features on your machine." I like to think that it's going to be the former, but if its the latter, then maybe EFF or CPSR or someone could start a campaign. Fortunately, I believe that there's a fair amount of consensus in DC that security technology moves too fast to be legislated in any way other than the most general terms. And, if we investigate general terms frequently used in legislation, we find that it's not prescriptive...
Thanks for the notice. What I meant to say was, "it's disgustingly easy for virii and worms to move throught email. (and then activate themselves)"
Re:This was completely predicable because...
on
Cryptogram: AES Broken?
·
· Score: 4, Informative
Umm... you might be a little confused as to how AES was selected. AES selection criteria were public, as were discussions on the strengths (and weaknesses) of finalist algorithms. In addition, I know two of the AES conference program committee personally, and believe that had the NSA attempted any shinanigans, they would have been resisted and/or reported loudly.
These knee-jerk reactions to the NSA being evil really are counter-productive. Of course there are evil people in the US Government; there are evil people in every walk of life. I just don't think there are enough evil people in the NSA to conspire against the "good" people in the NSA.
You might be too young to remember, but back in the 70's there was a big commotion about the NSA modifying IBM's original S-Boxes. Many people at that time claimed very loudly that the NSA was inserting a back door into the algorithm. The NSA was pretty tight-lipped about why they made these changes; I think they still are, BTW. As it turns out, the original IBM S-Boxes were more succeptable to differential cryptanalysis than the ones the NSA reccomended for use with DES.
Remember that the NSA has a dual mandate. First, it is supposed to intercept, decode, and/or decrypt foreign elint intercepts. This is one of the reasons why they're one of the largest employers of foreign language specialists. Second, they are supposed to develop technologies to protect US national interests. The two missions sometimes conflict, but ever since Herb Lin at the National Academy of Sciences published his report on why it is in the US' national interest to allow widespread use of strong crypto for domestic applications, most (if not all) of the NSA types I've encountered have supported the development and use of strong crypto.
Of course, there are federal groups that like to sneak into people's homes and install keyboard sniffers. But, if that is going to be your law-enforcement surveilance technique of choice, why bother forcing bad crypto on the populous?
Are you talking about the quantum computer that factored 15? Well... I hate to tell you this, but many 10 year olds can factor 15 in a tractable amount of time, but I don't feel threatened by their ability to "break" AES.
Well... actully it's more like the square root of 2^(100 - 16 - 20) days. The original attack indicated a complexity of 2^100. There's about 2^16 seconds in a day, and a standard PC can probably do 2^20 trial encryptions per day (um.. someone check my math on this... I haven't had very much coffee.) And you get the square root because I'm assuming it's sufficient to show that the ability to guess ANY plaintext / ciphertext pair in less time than brute force demonstrates the weakness. So, by my calculations, you're only safe for another 11 million years.
The Cryptonomicon.Net BLOG seems to imply that Mr. Schneier is doing a disservice to the community by limiting his dissing of algorithms only to the ones that competed with TwoFish... The blog author goes on to say that existing weaknesses in RC4 are probably more important than weaknesses in AES and asks the question, why didn't Bruce jump up and down about exploitable weaknesses found in RC4 over the last couple of years... It does sound a little like sour grapes...
Slashdot Mirror
A worry about Prescott is that it's supporting all the Trusted Platform felgercarb that's been in the news recently. Cryptonomicon.Net has a few links to related web sites and opinions in the article: Intel Debuts Prescott.
Readers interested in MacOS X security may want to check out this recent article at Cryptonomicon.Net: Creating an Encrypted Disk Image no MacOS X.
Cryptonomicon.Net has this story that proposes a mode of attack...
I'm not sure I understand what you mean by "practical." I found all of them to have very good things to say about practical implementations. If you're just looking for source code, then no, they don't offer source code. If you're looking to implement a crypto algorithm for use in a real system, I wouldn't try to do it without them. The commentary at the end of each chapter in HAC is somewhat scattered and haphazard, Koblitz' books present a lot of this information in a structured way.
Applied Crypto is certainly a quality, wide-ranging tome on crypto. For years though, there have been a couple very good books with more implementation details. The Handbook of Applied Crypto from Menezes, et al comes immediately to mind. Either of the two books by Neal Koblitz are excellent. I also like to recommend Decrypted Secrets from Bauer. The Handbook of Applied Crypto is available as a free download from the author's site:
Larry Cohen over at Cryptonomicon.Net has published this story questioning the commonly accepted belief that Theo de Raadt had his DARPA funding pulled because of Anti-War comments. The story makes the interesting point that SELinux and TrustedBSD are home-grown projects, while OpenBSD (and de Raadt himself) are more international. Mr. Cohen also mentions that FreeBSD is "more mainstream," which I guess means that it has more mainstream users. I guess it's a good point that we haven't hear comment from DARPA or from Jonathan Smith at the University of Pennsylvania. This leads to the question, is all this anti-war / free-speech hubbub just sour grapes?
This is a very valid point. A number of us like to kvetch about Microsoft deploying IE in a non-secure default configuration, we should probably ask the same question of open source developers. I think there are three issues here: what the OpenSSL team is doing, what the disto developers are doing, and what application developers are doing. The OpenSSL guys are writing the source code for a crypto library that can actually be made to be secure by default against timing attacks. This is, however, not the default configuration. So, because it's not the default configuration, the distro people grab the source, compile it with more or less the default options and move on. Application developers use crypto and ssl services from libcrypto or libssl and sort of "just expect it to work." Part of the problem is that the level of understanding of these issues is rather limited within the latter two groups listed above. I'm not saying they're morons. Far from it. But they're not crypto specialists, and there's documentation out there that will actually tell you that if you're using CRT, you're not succeptible to timing attacks. So, If you're not attending the conferences and hearing about advances on some of these types of attacks, you might not know that you would want to turn on blinding by default.
Actually, if you look at the Cryptonomicon.Net article about this attack, you can see that, in fact, blinding has been added to the OpenSSL code. The issue is whether or not it is turned on by developers.
Congratulations, you've found a reference to a completely different attack.
This is a relatively well known type of attack. You ask a private key holder to decrypt a bunch of things and ask it how long it took. To defend against these types of attacks, the private key holder can either a) decrypt only a few things for you (which is a bit anti-social if you're an SSL engine.) or b) lie to you about how long it took to decrypt the things you sent.
The second option is effectively what happens when blinding is turned on.
In addition to the comments on using XP to solve all your problems, you may want to consider searching the internet for:
As a FYI... if you don't want to run out and buy the XP books, you can view them online at O'Reilly's Safari website.
30 years? 1950 DA is supposed to swing by real close (or hit) in about 878 years, and I'm seriously frightened that we won't be able to get consensus in time to blast (or nudge) it out of it's orbit.
Go to http://www.cnn.com/2002/TECH/space/04/04/lost.aste roid/ for more info.
Yeah, but you can't use GPRS in the U.S. I was looking at upgrading my Cingular account to use GPRS until I noticed this handspring support page indicating that you can't upgrade yet.
I have since ditched my Treo and am eagerly awaiting a Sidekick.
On point number 1, you are absolutely, positively, 100% incorrect. The purpose of a certificate is not to establish that a SSL server operator is a "trustworthy business," it is to assert that a server operator has agreed to a set of behviors that will protect their private key, to provide an indemnification structure, and (optionally) verify that some trusted third party thinks you have a real address that can be served with legal papers should you not properly protect your private key.
To establish that a business is "trustworthy" is an entirely different proposition usually involving accountants, business consultants, and statisticians to evaluate the survey results from their customers. If someone is trying to tell you that a business will adhere to any agreement made with you simply because they are in posession of a valid SSL cert, they are blowing smoke up your kilt.
Also, I'm surprised that you would say that there is no cost associated with issuing a certificate. I'm sure that you administer multiple redundant secure Unix systems for fun, but most people actually have to get paid to do this work.
Just as a comment here... There's a reason it's not unreasonable to pay for certification that's not being mentioned here. The whole idea behind using a cert is to establish assurance in the identity of the ssl server. This identity assurance is established by the server proving posession of a private key related to a public key which has been certified by a certification authority. The certification authority uses a process supposedly outlined in their Certification Practice Statement to establish the identity of the ssl server. The CA itself has a certificate, certifying the identity of the person who owns the public key related to the private key that digitally signed the ssl server's certificate... it's the CA's self signed certificate! (yes, I'm ignoring the fact that some certificate chains have intermediate CAs, but that's for the advanced example.) Self signed certs are "bearer instruments" in a sense. If an adversary could get their self signed cert into your copy of Netscape or IE, then presumably they could start issuing bogus certs to inappropriate parties, and the whole chain of trust thing would go up in flames. To avoid this problem manufacturers of browsers, acting on behalf of their users (the relying parties) take special precautions to use root certs that have been verified to have really come from root CA's.
What you're paying for are the business operation costs to maintain the certificate issuing system and the indemnification costs.
So... you're probably wondering why you should care about all this when you're dealing with in internal site. Well... to a certain degree, you don't have to. This sort of trust chain is more useful in an environment where the two parties taking part in the communication have never met, nor have any of their "superiors" met. In a corporate environment, hierarchical organizations are common, and if you're dealing with a relatively large organization (say >300 people) it might be worth your while to investigate the idea of an internal CA.
WRT browsers, many corporate IT departments will devise a custom install for machines under their administrative control (you know, like a stock build of Win2k that gets ghosted onto new machines.) If this is the case in your organization, then it is (or at least it was) a relatively simple operation to install a new default root certificate into IE or Netscape (though I must admit, I've only done this myself with NS 4.something.)
As for CA software, if the only thing you're looking to do is create an internal root certificate that can be used to create certificates for internal ssl sites, OpenSSL will do this fine. Keon, Entrust, etc., etc. are generally justified when you want to start issuing client certs and establishing directories of internal certs & crls and revoking things...
uh... Who told you that DTDs and Schemas are not freely, openly, distributed? There is absolutely nothing I've seen that prevents you from downloading DTDs and/or Schemas. The documents defining XML, DTDs, and even Schemas are freely available (even though the Schema definition has gone through a great number of revisions, so it's sometimes hard to tell if you're using the right revision.)
Your second point seems to be a critique of encryption, not XML. Encryption is a fundamental technology for business, government, and personal information assurance. Think of XML as sort of ASCII meets the OSI presentation layer. If you start digging in the OSI protocols, you'll find reference to OIDs (Object Identifiers.) These things pop up everywhere, from SNMP traps to x.509 certificates. One thing you'll notice about OIDs is that some of them are well defined, and others are "internal use only." This has not led to protocols using OIDs being insecure or unuseful. DTDs and Schemas are in many ways the XML equivalent to OIDs. There will be a whole bunch of DTDs that are internal use only, but there's nothing wrong with this. OIDs that people tend to use in the real world are the ones about which we can find public documentation. DTDs and Schemas, I expect, will be the same way.
In defense of XML Information Assurance applications, I must say that the structured nature of XML allows applications to have a more refined model as to what in an XML document is encrypted, signed, decrypted, verified, hashed, and logged. If you've ever had to deal with ASN.1 and BER encoding, then you would know how wonderful XML is.
And then use WebObjects to do web-interface things... WebObjects + New Apple rackmount == sweet.
The rumor is that there was some sort of verbage about this in earlier drafts, but was removed at the behest of the software development community. I have been a TCF system developer for about 12 years now, and have always been depressed by the level of support for security features included in most consumer software.
However, NIST and NSA are starting to make some headway with the NIAP and other initiatives. At some point we'll probably need a security feature checklist and evaluation manual... Something much more detailed than what is found in the CC, and certainly more than what will ever be included in the NSSC.
Actually, it's not signed, sealed, and delivered just yet. There's a lot more input from govt. contractors coming in. While that may sound like a far cry from an "open process," many of the contractors are guys who worked on the early (D)ARPA internetworking projects.
Another thing to consider is that everything in the strategy for the private sector is optional. Rumor is that there was verbage in the strategy that would had "required" ISPs to distribute packet filtering firewall software to subscribers. That was taken out when Earthlink complained. So... if you ask me, it's not really a document to tell or mandate action from the general public. It looks more like a document that describes what the feds are going to do WRT information assurance on the net, and they want to go around and "raise awareness" in the program.
I will be interested to see what sort of spin gets put on these IA and data security in these town hall meetings. Will it be "Hey, this is what your government is doing, aren't we clever." or is it going to be "Hey, this is what we're doing, but all you peons are going to muck it up; you should let us legislate security features on your machine." I like to think that it's going to be the former, but if its the latter, then maybe EFF or CPSR or someone could start a campaign. Fortunately, I believe that there's a fair amount of consensus in DC that security technology moves too fast to be legislated in any way other than the most general terms. And, if we investigate general terms frequently used in legislation, we find that it's not prescriptive...
Thanks for the notice. What I meant to say was, "it's disgustingly easy for virii and worms to move throught email. (and then activate themselves)"
Umm... you might be a little confused as to how AES was selected. AES selection criteria were public, as were discussions on the strengths (and weaknesses) of finalist algorithms. In addition, I know two of the AES conference program committee personally, and believe that had the NSA attempted any shinanigans, they would have been resisted and/or reported loudly.
These knee-jerk reactions to the NSA being evil really are counter-productive. Of course there are evil people in the US Government; there are evil people in every walk of life. I just don't think there are enough evil people in the NSA to conspire against the "good" people in the NSA.
You might be too young to remember, but back in the 70's there was a big commotion about the NSA modifying IBM's original S-Boxes. Many people at that time claimed very loudly that the NSA was inserting a back door into the algorithm. The NSA was pretty tight-lipped about why they made these changes; I think they still are, BTW. As it turns out, the original IBM S-Boxes were more succeptable to differential cryptanalysis than the ones the NSA reccomended for use with DES.
Remember that the NSA has a dual mandate. First, it is supposed to intercept, decode, and/or decrypt foreign elint intercepts. This is one of the reasons why they're one of the largest employers of foreign language specialists. Second, they are supposed to develop technologies to protect US national interests. The two missions sometimes conflict, but ever since Herb Lin at the National Academy of Sciences published his report on why it is in the US' national interest to allow widespread use of strong crypto for domestic applications, most (if not all) of the NSA types I've encountered have supported the development and use of strong crypto.
Of course, there are federal groups that like to sneak into people's homes and install keyboard sniffers. But, if that is going to be your law-enforcement surveilance technique of choice, why bother forcing bad crypto on the populous?
Are you talking about the quantum computer that factored 15? Well... I hate to tell you this, but many 10 year olds can factor 15 in a tractable amount of time, but I don't feel threatened by their ability to "break" AES.
Well... actully it's more like the square root of 2^(100 - 16 - 20) days. The original attack indicated a complexity of 2^100. There's about 2^16 seconds in a day, and a standard PC can probably do 2^20 trial encryptions per day (um.. someone check my math on this... I haven't had very much coffee.) And you get the square root because I'm assuming it's sufficient to show that the ability to guess ANY plaintext / ciphertext pair in less time than brute force demonstrates the weakness. So, by my calculations, you're only safe for another 11 million years.
The Cryptonomicon.Net BLOG seems to imply that Mr. Schneier is doing a disservice to the community by limiting his dissing of algorithms only to the ones that competed with TwoFish... The blog author goes on to say that existing weaknesses in RC4 are probably more important than weaknesses in AES and asks the question, why didn't Bruce jump up and down about exploitable weaknesses found in RC4 over the last couple of years... It does sound a little like sour grapes...