Re: refactoring crypto handshakes (SSL in 3 easy steps)
There was a paper by Li Gong at an early CCS -- '93, I think, though it might have been '94 -- on the number of messages different types of authentication protocol took. It would be a good starting point. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Government Smart Card Initiative
Little progress on government-wide smart card initiative, and little surprise November 14, 2007 (Computerworld) More than three years after a presidential directive requiring federal government agencies to issue new smart-card identity credentials to all employees and contractors, progress on the mandate continues to be tediously slow. Most agencies appear to have missed by a wide margin an October 27 deadline by which they were supposed to have completed background checks and issued smart-ID credentials to all employees and contractors with 15 years or less of service. The so-called Personal Identity Verification (PIV) cards are supposed to be tamper-proof and to support biometric authentication features. PIV cards are designed to control access to federal computer networks and facilities and can be used across agencies. Federal agencies are mandated to issue them to all employees and contractor under Homeland Security Presidential Directive-12 of August 2004. Under the multi-phase initiative, agencies have until October 2008 to issue PIV cards to all their employees and contractors. Several government agencies contacted for this story did not respond to request for information on their implementation status. But an inspection of publicly posted information at IDmanagement.gov, a federal identity management site, showed that a large number of government agencies had barely begun issuing the cards just prior to the October deadline. Well below the Mendoza line For example, as of Sept. 1, the U.S. Department of Commerce had not issued even one PIV credential, though it listed over 40,000 employees as requiring it. As of October 19, the Social Security Administration had issued cards to 300 of its 65,000 employees, and to 429 of its approximately 20,000 contractors. On July 1, the U.S. Department of Energy had issued the new cards to 5 out of its 13,500 employees, and not a single one to its 98,000 or so contractors. Doing slightly better was the Department of State, which has issued the new ID credentials to 4450 of its 19,865 employees and to more than a quarter of its 7000 contractors by Sept. 14. Similarly, the Department of Labor has issued cards to 6450 of its 15,600 employees and about 400 of its 3000 contractors as of Sept. 1 Though the numbers are a far cry from where the agencies were required to be, they are not entirely unexpected. From the program's outset, security analysts and government IT managers warned that agencies would have a hard time meeting HSPD-12 implementation deadlines for a variety of technological and logistical reasons. This is a classic example of politically established deadlines that are not based on any reality at all. It is no more complicated than that, said Franklin Reeder an independent consultant and a former chief of information policy at the U.S. Office of Management and Budget (OMB). As best as I can tell, HSPD-12 deadlines were set without any real understanding of the enormity of what needed to be done or the costs involved in doing so, said Reeder, who is also chairman for the Center for Internet Security. The National Institute for Standards and Technology (NIST), which was originally entrusted with the task of coming up with the technical specifications for HSPD-12, did a great job in delivering the standards on schedule, Reeder said. Since then, agencies have been left with the unenviable task of trying in an unreasonably short time frame to replace their existing physical and logical access infrastructures with that required for the PIV cards, Reeder said. It's one of those situations where the technology itself is not complicated, but it does comprise many different pieces that have to be carefully integrated, said Hord Tipton, a former CIO with the U.S. Department of the Interior. The task involves a lot of cooperation between different groups within agencies that have traditionally not worked with each other, such as human resources, physical security and IT, he said, and sometimes it can also mean replacing ongoing agency efforts with the standards mandated by HSPD-12. The biggest example of this is the U.S. Department of Defense, which rolled out millions of its own IDs, called Common Access Cards. Those were based on a different standard, and the DoD is currently in the process of migrating their system to the PIV standard. Interoperability looms In addition to the internal issues, agencies also need to make sure their PIV card infrastructures are interoperable with those of other government agencies, Tipton said. This raises a whole set of other technology, standards, trust, control and political issues that agencies need to navigate. A shared service set up by the General Services Administration (GSA) to help agencies enroll employees into the PIV program and issue the new cards to them is also still in the process of ramping up according to Neville Pattison, vice president of business development and government affairs at
Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Tue, Nov 13, 2007 at 08:35:52AM +0200, [EMAIL PROTECTED] wrote: The extra messages might be irrelevant for cryptography, but they're not irrelevant for security or functionality. E.g. in SSL, you have capability/feature negotiation (cipher suites, trusted CAs, in TLS 1.2 also signature algorithms, etc.) So, this is a good place to attempt to use this method. Data to be sent: 1) supported capabilities on the client 2) supported capabilities on the server 3) negotiated capabilities Dependencies: 1) No dependencies (first message from client to server) 2) No dependencies (first message from server to client) 3) Depends on #1 and #2 Results: 3 messages 1-1.5 RTTs (one if there's a simultaneous open, which is rare) So unless I'm missing something, we're still at 3 messages. Aside: I would like to point out that TCP-based protocols have the latency disadvantage of having to do a 3-way handshake before transferring any data. If you were to design a new IP protocol, you could do the key exchange within the handshake, which would save 3 messages, but may be vulnerable to a resource-consumption attack on the CPU. I wonder if we here could develop a handshake that was cryptographically secure, resistant to CPU DoS now, and would be possible to adjust as we get faster at doing crypto operations to reduce latency even further. Basically an easy knob for balancing high latency and DoS resistance vs. crypto overhead and low latency. It should be adjustable on either end without altering the other. -- Life would be so much easier if it was open-source. URL:https://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp8fMSK6gOb3.pgp Description: PGP signature
fyi: Colossus in action
BP being Bletchley Park of course. http://www.bletchleypark.org.uk/ =JeffH From: David Hansen [EMAIL PROTECTED] Subject: Colossus in action To: [EMAIL PROTECTED] Organization: Spidacom Limited Just in case anyone is as ill informed as me, I was delighted to read at http://news.bbc.co.uk/1/hi/technology/7094881.stm that the rebuilt Colossus is or is about to be used on a message enciphered on a Lorenz machine and transmitted from Germany. Following the links from that page I see that the message will be intercepted using the radio equipment of the time before the Colossus tries to work out the settings. There will be parallel effort with modern radio equipment and computers. It should be an interesting race. I admire those who had the enthusiasm to rebuild the machine and who had the contacts to get hold of the plans and notes that remained. The last time I took a particular interest in the project, some years ago, they were trying to find the right sort of valve and had just completed the framework for hurtling paper tape round and round. - -- David Hansen, Edinburgh I will *always* explain revoked encryption keys, unless RIP prevents me http://www.opsi.gov.uk/acts/acts2000/00023--e.htm#54 --- Message 2 From: John Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Colossus in action Date: Thu, 15 Nov 2007 14:06:02 + On Nov 15, 2007 9:51 AM, David Hansen [EMAIL PROTECTED] wrote: I admire those who had the enthusiasm to rebuild the machine and who had the contacts to get hold of the plans and notes that remained. The last time I took a particular interest in the project, some years ago, they were trying to find the right sort of valve and had just completed the framework for hurtling paper tape round and round. We visited a couple of weeks ago and I took some snaps of the rebuild project http://flickr.com/photos/tug/sets/72157602953115982/ BP has improved markedly since we last visited (about three years ago). However the guided tours are even worse than ever (our guide remonstrated with passers by for taking whilst he was droning on). Take one of the excellent electronic guides and do your own tour. John Wilson -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
No PAL please, we're British
According to this BBC story until fairly recently the British military refused to have PALs on nuclear weapons. http://news.bbc.co.uk/1/hi/programmes/newsnight/7097101.stm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: refactoring crypto handshakes (SSL in 3 easy steps)
There's a dependency from negotiated capabililities to the cryptographic things included in the first message from client to server (since e.g. what algorithm is used by the client, or even what certificate is selected, depends on these non-crypto capability/feature parts.) But as James pointed out, you could probably handle this in optimistic mode; i.e. make a guess what the negotiated capabilities are likely to be, and fall back to more RTTs if the guess is wrong. (BTW, usually we also want the capability negotiation to be secure; SSL simply exchanges MACs of all messages once the key for MAC has been agreed on. Would this add 0.5 or 1RTT? Or perhaps there's some clever way to do it without additional RTT?) Best regards, Pasi -Original Message- From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 14 November, 2007 21:46 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: cryptography@metzdowd.com Subject: Re: refactoring crypto handshakes (SSL in 3 easy steps) On Tue, Nov 13, 2007 at 08:35:52AM +0200, [EMAIL PROTECTED] wrote: The extra messages might be irrelevant for cryptography, but they're not irrelevant for security or functionality. E.g. in SSL, you have capability/feature negotiation (cipher suites, trusted CAs, in TLS 1.2 also signature algorithms, etc.) So, this is a good place to attempt to use this method. Data to be sent: 1) supported capabilities on the client 2) supported capabilities on the server 3) negotiated capabilities Dependencies: 1) No dependencies (first message from client to server) 2) No dependencies (first message from server to client) 3) Depends on #1 and #2 Results: 3 messages 1-1.5 RTTs (one if there's a simultaneous open, which is rare) So unless I'm missing something, we're still at 3 messages. Aside: I would like to point out that TCP-based protocols have the latency disadvantage of having to do a 3-way handshake before transferring any data. If you were to design a new IP protocol, you could do the key exchange within the handshake, which would save 3 messages, but may be vulnerable to a resource-consumption attack on the CPU. I wonder if we here could develop a handshake that was cryptographically secure, resistant to CPU DoS now, and would be possible to adjust as we get faster at doing crypto operations to reduce latency even further. Basically an easy knob for balancing high latency and DoS resistance vs. crypto overhead and low latency. It should be adjustable on either end without altering the other. -- Life would be so much easier if it was open-source. URL:https://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Possible backdoor in FIPS SP 800-90 PRNG
Slashdot this morning has a posting about the possibility of a back door in the elliptic curve random number generator in FIPS SP 800-90. http://it.slashdot.org/article.pl?sid=07/11/15/184204 has links to an article by Bruce Schneier at wired.com, the standard, and the presentation with the new result. The work is by Dan Shumow and Niels Ferguson and was presented at the Crypto 2007 rump session. Basically there are two elliptic curve points, and if you know the discrete logarithm of one relative to the other, you can reverse engineer the internal state just from the RNG outputs. It's a very nice piece of analysis. The problem is that NIST publishes a pair of points that they suggest you use, in Appendix A.1, without giving any hint of how they were derived. This leaves open the possibility that they were selected in such a way as to exploit the Shumow/Ferguson back door. Now, here's the strange thing. In Appendix A.2 NIST says that you can use your own pair of points if you want to. But, they caution very strongly that in that case, anyone relying on the PRNG should verify that the pair of points were generated randomly. They describe a specific procedure for generating random points in a provable way (via hashing some other data) and require that the seeds that were used be saved and made available to the verifier. They don't say anything about why this is important, but the work by Shumow and Ferguson now makes it clear. Otherwise there is the possibility of a very serious back door. So this raises the obvious question, why didn't NIST publish the seeds that were used to generate the default points from Appendix A.1? It seems odd that they are so insistent about using a verifiable procedure to create points, and then they don't say whether they followed it themselves. If they did use that procedure, NIST could simply publish the seeds for the point generation and everyone will be able to verify that the points are random and there is no back door. Unfortunately there is a complication, which is that one of the pair of points is inherited from FIPS 186-3, the Digital Signature Standard. The EC PRNG uses the curve and base point from EC DSS. It then chooses another point, and the two points are used for the PRNG. It's not particularly likely that the base point from EC DSS was generated via the randomizing technique prescribed for the EC RNG. And even if the 2nd point for the EC RNG is in fact generated randomly and they can prove it, it would not rule out the possibility that the base point from EC DSS had actually been pre-selected to allow for a back door. It is crucial that both points be generated randomly for the EC RNG to be secure. Ironically, the EC DSS standard does publish a seed used for a PRNG to generate the elliptic curves, so as to assure that they are random. However based on my reading of IEEE P1363 which tells how to do this, it does not appear that the seed constrains the base point, only the curve parameters. Unless NIST did use a verifiably random method to generate the base points in EC DSS and the 2nd points in EC PRNG then there is no foundation for security. Therefore the only reasonable way forward is for NIST to either publish the seeds that were used for these points, if they exist, or to revise the standard to use new points and publish the seeds for both of them. There is no need to re-use the points from FIPS 186-3, a new pair of points should be chosen for the PRNG via the specified randomization. Hal Finney PGP Corporation - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
