Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Thu, Nov 08, 2007 at 01:49:30PM -0600, [EMAIL PROTECTED] wrote: PREVIOUS WORK: Three messages is the proven minimum for mutual authentication. Last two messages all depend on the previous message, so minimum handshake time is 1.5 RTTs. Kerberos V manages in one round-trip. And it could do one round-trip without a replay cache if it used ephemeral-ephemeral DH to exchange sub-session keys. (OTOH, high performance, secure replay caches are difficult to implement, ultimately being limited by the number of write to persistent storage ops that the system can manage.) I think you might want to say that three messages is the minimum for mutual authentication with neither a replay cache nor a trusted third party negotiating a key for use during the authentication exchanges. Or something along those lines. Of course, you might claim that the TGS exchanges should be added to the number of messages needed for AP exchanges, but if you re-authenticate often then you amortize the cost of the TGS exchanges over many AP exchanges. I think first and foremost we need authentication protocols to be secure, while at the same time being algorithm agile. I think you can generally manage that in 1.5 round-trips optimistically, more when optimistic negotiation fails. And you can do better if you have something like a KDC that can do negotiation out of band. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: refactoring crypto handshakes (SSL in 3 easy steps)
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.) which IMHO *is* important for security (if you consider the security implications of deploying this over tens of years and hundreds of millions of hosts). (But yes, there are variations of SSL where a smaller number of RTTs might have been sufficient..) Best regards, Pasi -Original Message- From: travis+ml-cryptography Sent: 08 November, 2007 21:50 To: Cryptography Subject: refactoring crypto handshakes (SSL in 3 easy steps) ASSUMPTIONS: Network latency is important, and will only become more so, since light won't go faster in a given medium, and we can't do better than c, ever. PROPOSED SOLUTION: Refactor protocol to minimize number of interlocked steps. Specifically, reduce the number of messages. METHODOLOGY: Identify data which must be transmitted, and identify their dependencies. Send data on first outbound message to peer after all its dependencies are available (i.e. on the step after it is received). Each transmission is a sweep of one level of the dependency tree, starting at the root and working downward. PREVIOUS WORK: Three messages is the proven minimum for mutual authentication. Last two messages all depend on the previous message, so minimum handshake time is 1.5 RTTs. EXAMPLE: First examine SSL with Mutual Auth, which is detailed here: http://en.wikipedia.org/wiki/Image:Ssl_handshake_with_two_way_ authentication_with_certificates.png Here is a refactored version of the important messages: C-S: hello, RNc, client cert, enc_S(client_cert) S-C: server cert C-S: enc_S(PMS) DISCUSSION: Providing the datum as soon as its dependencies are satisfied is well-studied in processor design. One may have extra messages, but they are implementation artifacts, completely irrelevant to the cryptography. Network protocol libraries advance through time monotonically and thus are analogous to LR(1) language parsers which parse from left to right and are only able to look at the next token (message); perhaps we can apply what we already know about them to create unambiguous crypto handshakes with respectable error handling. Sending one layer of the dependency tree at once is like a synchronous circuit; one could also fire off messages as soon the data becomes available, like an asynchronous circuit, which may reduce overall time of the handshake due to computation by the endpoints. However, it is an implementation detail, not important to this analysis. OPEN QUESTIONS: When would a handshake require more? Is there such a thing, in any extant ZKS or PFS systems? COMMENTS? -- 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]
[Fwd: ISACA to Host an Enterprise Key Management Infrastructure Workshop]
A reminder of the Enterise Key Management Infrastructure (EKMI) Workshop on November 15th in San Francisco. Thanks. Arshad Noor StrongAuth, Inc. Original Message Subject: ISACA to Host an Enterprise Key Management Infrastructure Workshop Date: Sun, 21 Oct 2007 21:49:40 -0700 From: Mike Nelson [EMAIL PROTECTED] To: ekmi [EMAIL PROTECTED] EKMI TC, The San Francisco ISACA chapter is pleased to announce the opening of registration for the ³Enterprise Key Management Infrastructure Workshop to be held at the Hotel Nikko (222 Mason St., SF) on Thursday, November 15. This will be a morning session, breakfast followed by the workshop until noon. We're exploring now the possibility of extending the session into the afternoon for an optional hands-on exercise. [This is now confirmed. It is optional, and those interested in staying for the lab session must bring their own laptop to perform the exercise. The laptop must have either Windows XP or Linux with at least 512MB of memory and 2GB of free disk space.] I hope you can attend and encourage your collogues to do the same. More information can be found at http://sfisaca.org. -- Mike Nelson, CAP, CISA, CISM, CISSP, ITIL [EMAIL PROTECTED] or [EMAIL PROTECTED] www.securenet-technologies.com or www.fisma.us blog: mrfisma.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
People side-effects of increased security for on-line banking
Sometimes the side-effects are as significant as the direct effects -- Jerry Story from BBC NEWS: http://news.bbc.co.uk/go/pr/fr/-/2/hi/technology/7091206.stm Fears over online banking checks By Mark Ward Technology Correspondent, BBC News website Complicated security checks could be undermining confidence in online banking, warn experts. Security extras such as number fobs, card readers and password checks might make consumers more wary of net bank websites, they fear. The warning comes as research shows how phishing gangs are targeting attempts to grab customer login details. But the UK body overseeing net banking says figures show criminals are getting away with less from online accounts. Security check In a bid to beat the bad guys many banks have added extra security checks to the login name and password typically used to get access to an account. Some, such as Lloyds, have trialled number generating key fobs and Barclays is trialling chip and pin card readers. Others have tried systems that check a customers PC and then ask that person to select which image they chose from a set they were shown previously. But, said Garry Sidaway from ID and authentication firm Tricipher, all these checks could be making consumer more nervous about using online banking. The banks have to make this channel secure, he said, but there is crumbling confidence in it. Andrew Moloney, financial services market director for RSA Security, said banks were well aware that their efforts to shore up security around online banking could have a downside. It registers as a concern, he said, there could be too much security and there's a danger of over-selling a new technology. This is not just about combating fraud, he added. It's about customer retention rates, user experience and customer satisfaction. The misgivings about beefed up security around online banking come as the UK government's Get Safe Online campaign issues a survey which shows the risks people are taking with login details. These lax practices could prove costly as cyber fraudsters gradually shift their attention to Europe following moves in the US to combat phishing. In late 2005 the US Federal Financial Institutions Examination Council (FFIEC) issued guidelines which forced banks to do more to protect online accounts. Phishing statistics show a rapid move by the fraudsters to European banks and, said Mr Moloney, to smaller European banks using less protection. Lists of phishing targets gathered by security companies show a huge shift away from big bank brands such as Citibank and Bank of America to Sparkasse, VolksBank and many others. A spokeswoman for the Association for Payment and Clearing Services (Apacs) which oversees online banking said its figures showed that the message about safe banking was getting through. Statistics released in October indicated that online banking fraud (including phishing) for the first six months of 2007 was down 67% over the previous year. During the same time period the number of phishing attacks rose by 42%. The reason we are seeing that fall, despite the increase in phishing attacks, is because consumers are becoming more aware of how to protect themselves, said the spokeswoman. But, she added, what we are still seeing happening is people falling foul of phishing attacks. The spokeswoman urged people to be careful with login details to bank accounts and exercise caution when using e-mail and the web. Published: 2007/11/13 09:33:59 GMT ? BBC MMVII
Re: refactoring crypto handshakes (SSL in 3 easy steps)
[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.) You can handle this by client making a guess, perhaps based on past experience, as to whether its initial request for preferred protocol is likely to be accepted, and if it thinks it probably will be, going ahead on the assumption it will be, rather than waiting for the round trips to complete. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
