Re: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
Marsh Ray writes: >> CryptoAPI: A handful of guys at Microsoft > >I always kind of thought this one looked like someone went a little wild with >the UML modeling tools. I've been following it since CryptoAPI 1.0, initially it was a fairly straightforward, basic API, but it's been bloated up over time on the design principle of of "gimme an API to do X" as required, so it evolved rather than being designed as such. For example CryptDeriveKey() is really CryptProcessPasswordForWindows() (or perhaps CryptLoadContextFromHash()) rather than something where you can do PBKDF2, PGP S2K, the TLS and SSH PRFs, and so on. In addition many of the lower-level functions in CryptoAPI are realy only useful for implementing higher-level bits of CryptoAPI, but not as a general-purpose API for crypto. So if your goal is "I want to do crypto the Windows way" then it's perfectly fine. If OTOH it's "I want to read certs from the Windows cert store for use in a non-CryptoAPI app" (for example) then you're in for quite a bit of pain. >OK, but when one of the buckets has 0 observations in it what is it proving >exactly? That no successful crypto API has ever been designed by a committee? We have (at least) CDSA, TCG, and GSS-API, and none of those have seen any significant adoption (by "significant" I mean at the same level as CryptoAPI, OpenSSL, etc). >It would say a lot more if there were some examples of committee-designed >crypto APIs that nobody wanted to use because of those noticeable effects. See above. Note that the two lists were of "Successful crypto APIs", not "Any kind of crypto API". I'm not aware of any designed-by-committee crypto API that's had any real penetration in the marketplace. >Netscape/Mozilla's NSS might be another interesting data point. How much of that is PKCS #11 and how much is non-PKCS #11 NSS? But yeah, that'd be another example. >Having a concrete API can keep the design grounded. There are some things in >TLS that have *no* representation in any sane API. This could only have >occurred by the design leading the implementation a little too far. Actually I was surprised during the discussion of adding explicit IVs in TLS 1.1 that people brough up API issues to argue for or against particular designs. I'd never seen that in other WGs. >There already are crypto APIs being defined in RFCs, they're just ad-hoc >and lacking interoperability. E.g. >http://tools.ietf.org/html/rfc6234#section-8.1 Does anyone or anything of any significance use that API? I looked at it when the RFC was published and, not to put too fine a point on it, it didn't seem to be based on any great implementation experience. >The purpose of the IETF considering APIs in general isn't *just* that we'll >all get some huge new API to use and which will be considered a failure if the >whole world doesn't move to it immediately. Just the process of defining an >API holds potential to improve the quality of the protocols and specification. But almost anything (including recreational pharmaceuticals) can act to "improve the quality of the protocols and specification". Is bringing API considerations into the design process a suitable cost/benefit tradeoff? Could you achieve the same (or better) with a few beers worth of analysis? The biggest factor that would affect IETF protocol design in my opinion is a requirement to provide legitimate real-world (not gedanken-experiemtn) usage cases. That requirement alone would instantly halve (or more) the complexity of most security protocols (and, by extension, improve the quality etc etc). For my part I'd be absolutely terrified of the IETF trying to specify an API. The strength of IETF specs is that they're purely functional, so you can implement them in C, Java, PHP, or by waiting for single event upsets to flip the appropriate RAM bits, and as long as you get the same bits on the wire you're OK. OTOH if a WG ever gets asked to design an API it'll make Bosnia look like a cakewalk. Just the bikeshedding over which language bindings to use could take years if not decades. Then there's synchronous vs. asynchronous interfaces (the HW guys want async for performance, the software guys want sync because async is hard), how do we make things thread-safe (does the caller have to do it, or should we have abstract locking objects, or does the code library do it), should we make it more OO or more functional... this isn't just a bikeshed, it's a twelve-storey bikeshed with a magnificent entrance hall, carpeting throughout, 24-hour portage, and an enormous sign on the roof, saying "This Is a Large Bikeshed". See "CDSA" for an example. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
On Wed, Jun 22, 2011 at 8:17 AM, Peter Gutmann wrote: > Marsh Ray writes: > >>Right, so one of the lessons learned here was that if IETF had considered >>APIs and not just protocols those bugs in TLS would have been found long ago. > > A pen-tester I know once found a (fairly serious) security hole under the > influence of (equally serious) pharmaceuticals, but I wouldn't recommend the > IETF adopting that as a design strategy, just as I'd be pretty terrified of > the result of the IETF trying to standardise a crypto API. If you look at the > history of all the widely-used crypto APIs: > > Crypto API designed by an individual or a single organisation: > > CryptoAPI: A handful of guys at Microsoft > PKCS #11: Someone at RSA (I've heard different stories). > JCE: A couple of guys at Sun. > OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim > Hudson. > Crypto API designed by a committee: > > > > > QED, I think. Apparently esteemed Mr. Gutmann is too modest to include cryptlib. And also Wei Dai's Crypto++ API probably should be in that list. (Jack Lloyd's Botan was already mentioned in a separate post, but should be included as well.) However, I'm not sure the assumption that CICM is being designed by committee because it is seeking to go the IETF working group route is a valid one. For one, Lev mentioned that it has arose from work that Mitre did for the Air Force which means at least there is some basis for previous design and I'd bet that it was designed by a relatively small development team. If anything, I would think that CICM seeking the path of an IETF working group in order to be standardized would parallel the path that was done followed by GSS-API en route to RFC 2743 and before that RFC 2078 and before that RFC 1508. (I was not involved in any of those RFCs, but I presume that they also went through some similar process with an IETF working group, no?) Besides, if anything, I think that crypto APIs would suffer from too little involvement from professional cryptographers than it would from too much involvement. (Or are professional cryptographers the type of people that if you back 5 of them into a corner they will have at least 8 different opinions amongst themselves? ;-) Anyhow, excuse my ignorance, but wouldn't time be better spent critiquing the actual proposed CICM draft specification at http://datatracker.ietf.org/doc/draft-lanz-cicm/?include_text=1 rather than setting up and knocking down seemingly straw men arguments? Thanks for hearing out a crypto novice. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] 17% smaller DES S-box circuits: 44.125 and 32.875 gates per S-box
Hi, We've just released those, as part of John the Ripper 1.7.8, but freely licensed for reuse anywhere else. Our understanding is that S-box expressions themselves are mathematical formulas and thus are not subject to copyright. The specific code implementing them is licensed under a heavily cut-down BSD license (no restrictive clauses). Roman Rusakov and I have been working on this for a long while, with Rapid7's sponsorship. The primary idea was Roman's, and he did all the work to generate the S-box expressions (which took months on his overclocked water-cooled quad-core machine with 24 GB RAM). My humble contribution was code generation and feedback to Roman such that we'd have not only the smallest gate count, but also decent program code (not requiring too many registers, reasonably efficient on 2-operand architectures, yet containing inherent parallelism). In the end, we had thousands of same-gate-count "circuits" to choose from for some of the S-boxes and some of the target instruction sets. For AND, OR, XOR, NOT, and AND-NOT gates (MMX/SSE2/AVX, typical RISC CPUs): Gate counts: 49 44 46 33 48 46 46 41 Average: 44.125 Previous best result: 53.375 (or 51 with XNOR gates), by Matthew Kwan For "bit select" gates (Cell, PowerPC with AltiVec, AMD XOP, high-end ATI GPUs): Gate counts: 36 33 33 26 35 34 34 32 Average: 32.875 Previous best result: 39.875, by Dango-Chu More detail: http://www.openwall.com/lists/john-users/2011/06/22/1 Collection of previous results: http://download.openwall.net/pub/projects/john/contrib/bitslice-des/ I'd appreciate any comments, and once again - feel free to use/reuse. Thanks, Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
> What happens if the bad guy just strips the signature? What are the > circumstances under which an OS or user+OS will refuse to run code that just > isn't signed at all? In the case of Microsoft Clickonce, the Install Dialog is changed from "Publisher: Discount Bob's Software & Hanggliding" to "Publisher: Unknown Publisher" and the icon from a yellow shield to a red shield. I took a look at Man-in-the-Middling Clickonce deployments last summer. Stripped the signature, decompiled to IL, injected code, and recompiled all as part of a transparent proxy. http://seclists.org/bugtraq/2010/Jul/164 A similar project is Evilgrade: http://blog.infobytesec.com/2010/10/evilgrade-20-update-explotation.html although that's a framework for targeting different applications, each one possibly behaving differently. -tom ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
> > Just to split hairs, malware has stolen signing keys for years, but it's only > in the last few years that malware vendors have started using them. Maybe that's it -- it's DRM for the malware vendors, to ensure that other bad guys don't steal their code... --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
On Wed, Jun 22, 2011 at 7:17 AM, Peter Gutmann wrote: > Marsh Ray writes: >>Right, so one of the lessons learned here was that if IETF had considered >>APIs and not just protocols those bugs in TLS would have been found long ago. > > A pen-tester I know once found a (fairly serious) security hole under the > influence of (equally serious) pharmaceuticals, but I wouldn't recommend the > IETF adopting that as a design strategy, just as I'd be pretty terrified of > the result of the IETF trying to standardise a crypto API. If you look at the > history of all the widely-used crypto APIs: > > Crypto API designed by an individual or a single organisation: > > CryptoAPI: A handful of guys at Microsoft > PKCS #11: Someone at RSA (I've heard different stories). > JCE: A couple of guys at Sun. > OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim > Hudson. > > Crypto API designed by a committee: > > QED, I think. I don't think you've demonstrated what you wanted to. Of your examples none were designed by any committees, and all had little or no open participation review by a large body of reviewers with diverse experiences. If anything you've demonstrated the opposite of what you thought you were demonstrating. Argument by ridicule does produce chuckles, but not necessarily good results. The IETF isn't a committee. If you think design by committee leads to failure (many of us do) and that the IETF means design-by-committee, then why does the IETF have any successes? The answer is probably not "luck" -- perhaps it's luck in the sense that by pure luck we got the right culture for success in spite of being a committee (but it's not), or perhaps the answer is that there are many more failures than successes at the IETF. But then, the IETF isn't a committee. I could go on and bore the list. We probably now have enough collective experience with crypto APIs that we could design one that doesn't suck. Yes, we could also design more sucky crypto APIs. And we do need crypto APIs. Someone is bound to try to fill that need. By your estimation no one person nor group can design a decent crypto API and we shouldn't try either. We know you're a master of ridicule, but leaving us with no choices is hardly helpful. Lastly, I'm not advocating APIs in all cases. I'm advocating *abstract* APIs for *protocols* and I have given strong circumstantial evidence that having such APIs is important, that not having them has caused real problems. That said, we have crypto APIs because we need them; if we want better ones I do think the IETF is best placed to produce them. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
On 06/22/2011 08:04 AM, Marsh Ray wrote: On 06/22/2011 09:40 AM, Steven Bellovin wrote: http://www.darkreading.com/advanced-threats/167901091/security/application-security/231000129/malware-increasingly-being-signed-with-stolen-certificates.html Not surprising to most readers of this list, I suspect... The interesting thing is that code signing schemes have been around for decades but 2010 is the first time malware even bothered to steal signing keys. :-) Not true; an attack on VeriSign in 2000 caused them to issue two Class-3 digital certificates in the name of Microsoft. The perpetrators were never caught and to this day, Windows ships with a specific CRL that identifies these two certificates - you'll find them in your cert trust- store: http://support.microsoft.com/kb/293818 There have been other private-key thefts since 2000, but the VeriSign attack is the earliest I can recall in my PKI-related career. Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
Marsh Ray writes: >It's usually more useful as a means for an platform vendor to enforce its >policies on legitimate developers than as something which delivers increased >security to actual systems. Symbian being a prime example. With Android it's easier, you just publish the private key and then all these hassles go away. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
Marsh Ray writes: >On 06/22/2011 09:40 AM, Steven Bellovin wrote: >> http://www.darkreading.com/advanced-threats/167901091/security/application-security/231000129/malware-increasingly-being-signed-with-stolen-certificates.html >> >> Not surprising to most readers of this list, I suspect... > >The interesting thing is that code signing schemes have been around for >decades but 2010 is the first time malware even bothered to steal signing >keys. :-) Just to split hairs, malware has stolen signing keys for years, but it's only in the last few years that malware vendors have started using them. It's also been evolving for awhile, see Jarno Niemelä's blog at F-Secure for more on this, or his summary "It.s Signed, therefore it.s Clean, right?" from last year's CARO workshop. >What happens if the bad guy just strips the signature? [...] See Jarno's talk on some of the techniques that the bad guys have used over time. >MSIE displays the name to the user when prompting to run ActiveX controls. Yup, names like "Trusted program" and "Click OK to continue" and "Approved by Microsft" and the like. In the 1980s people used to create zip files with names like "CON:" in them for a joke, two decades later the same types of trick still work just fine. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
On 06/22/2011 10:04 AM, Marsh Ray wrote: Code signing. Occasionally useful. I meant to add: It's usually more useful as a means for an platform vendor to enforce its policies on legitimate developers than as something which delivers increased security to actual systems. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digitally-signed malware
On 06/22/2011 09:40 AM, Steven Bellovin wrote: http://www.darkreading.com/advanced-threats/167901091/security/application-security/231000129/malware-increasingly-being-signed-with-stolen-certificates.html Not surprising to most readers of this list, I suspect... The interesting thing is that code signing schemes have been around for decades but 2010 is the first time malware even bothered to steal signing keys. :-) What happens if the bad guy just strips the signature? What are the circumstances under which an OS or user+OS will refuse to run code that just isn't signed at all? 64-bit drivers for Windows Vista and later. Some locked down "walled garden" environments, almost always jail-breakable in practice. When does the name of the party that signed it actually matter? What if the bad guy signs the malware with some unrelated party's cert? When any valid signature will do, the effective security provided by the code signing scheme decreases exponentially with the total number of signing certificates issued. MSIE displays the name to the user when prompting to run ActiveX controls. The user is expected to be able to determine if the name on the control is correct and refuse to run it if not. Even if the correct party is required to have signed the code, the bad guy can commonly redistribute an older (properly signed) version with a security hole which he then exploits. Thus revocation is even more critical than with identity certificates. Code signing. Occasionally useful. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Digitally-signed malware
http://www.darkreading.com/advanced-threats/167901091/security/application-security/231000129/malware-increasingly-being-signed-with-stolen-certificates.html Not surprising to most readers of this list, I suspect... --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
On 06/22/2011 07:17 AM, Peter Gutmann wrote: Crypto API designed by an individual or a single organisation: CryptoAPI: A handful of guys at Microsoft I always kind of thought this one looked like someone went a little wild with the UML modeling tools. PKCS #11: Someone at RSA (I've heard different stories). One could do worse. JCE: A couple of guys at Sun. This one underwent breaking changes which, to this day, requires us to maintain two sets of code where I work. OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim Hudson. I'll withhold comment on this one until the documentation is complete. :-) And last but not least let us not forget http://botan.randombit.net/ by our gracious email list host! Crypto API designed by a committee: QED, I think. OK, but when one of the buckets has 0 observations in it what is it proving exactly? Maybe simply that most crypto APIs in common use are designed by a "handful" or fewer guys. Which probably counts for something, but I think it's not so obviously prescriptive. * Perhaps the effect you're seeing could be explained by a crypto API being a relatively straightforward data-in data-out type of thing. Or at least that's a workable oversimplification. * It would say a lot more if there were some examples of committee-designed crypto APIs that nobody wanted to use because of those noticeable effects. * Netscape/Mozilla's NSS might be another interesting data point. WRT IETF involvement: * A typical IETF spec doesn't seem to have any more authors or significant contributors than a "small" engineering team at a big company. * Having a concrete API can keep the design grounded. There are some things in TLS that have *no* representation in any sane API. This could only have occurred by the design leading the implementation a little too far. * There already are crypto APIs being defined in RFCs, they're just ad-hoc and lacking interoperability. E.g. http://tools.ietf.org/html/rfc6234#section-8.1 The purpose of the IETF considering APIs in general isn't *just* that we'll all get some huge new API to use and which will be considered a failure if the whole world doesn't move to it immediately. Just the process of defining an API holds potential to improve the quality of the protocols and specification. The prior policy of IETF seemed to frown on formal consideration of APIs. I think that should definitely change, although it's not really an argument in support of this specific proposal. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Repeated Encryptions Considered.... ?
Ian G writes: >The typical reasons for not using TLS would be >[...] >(c) it only delivers a relatively small subset of a fuller security model. That's a legitimate reason for using JS crypto. What TLS gives you is the archetypal armoured car from the guy who lives on a cardboard box to the guy who lives in a park bench, while JS crypto of the PDU gives you crypto from the teller at park-box-guy's bank to the teller at cardboard-bench-guy's bank. Using both is perfectly sound, TLS provides the blanket protection against passive eavesdroppers and the JS PDU-encryption protects the message as a whole from endpoint to endpoint. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
Marsh Ray writes: >Right, so one of the lessons learned here was that if IETF had considered >APIs and not just protocols those bugs in TLS would have been found long ago. A pen-tester I know once found a (fairly serious) security hole under the influence of (equally serious) pharmaceuticals, but I wouldn't recommend the IETF adopting that as a design strategy, just as I'd be pretty terrified of the result of the IETF trying to standardise a crypto API. If you look at the history of all the widely-used crypto APIs: Crypto API designed by an individual or a single organisation: CryptoAPI: A handful of guys at Microsoft PKCS #11: Someone at RSA (I've heard different stories). JCE: A couple of guys at Sun. OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim Hudson. Crypto API designed by a committee: QED, I think. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
