Re: Strength in Complexity?
Arshad Noor [EMAIL PROTECTED] writes: Ben Laurie wrote: As such, I'm not seeing much value. That may be because you are a cryptographer. If you were the CSO, an Operations Director, or an Application Developer in a company that had to manage encryption keys for 5,000 POS Terminals, 10,000 laptops, desktops and servers across multiple data-centers and 400 stores, you would see it very differently. I'm not sure I would see it differently from Ben. There are existing deployed solutions like Kerberos that scale far beyond that and work just fine, and actually address all the things this protocol seems to leave as an exercise to the reader. And yes, they're in use in real companies at gigantic scales. (Indeed, Kerberos is central to Microsoft's technologies these days.) Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
On Sun, 3 Aug 2008, Arshad Noor wrote: A more optimistic way of putting this, Ben, is to state that EKMI allows domain-experts of underlying components to address the complex issues of their domain in ways that they deem best, while providing value on top of those components. I see no reason to reinvent any of the components - despite their imperfections - when they serve my purpose very well. The business goal here is not cryptographic elegance or perfection, but a solution to a problem without creating new vulnerabilities. ... or in other words, EKMI leaves all of the hard/impossible problems to be solved by somebody else. I'd have to agree with Ben that I'm not seeing the value add of an additional layer of complexity. That may be because you are a cryptographer. If you were the CSO, an Operations Director, or an Application Developer in a company that had to manage encryption keys for 5,000 POS Terminals, 10,000 laptops, desktops and servers across multiple data-centers and 400 stores, you would see it very differently. That's an interesting presumption that you're making -- are you familiar with your audience? cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger wrote: There are existing deployed solutions like Kerberos that scale far beyond that and work just fine, and actually address all the things this protocol seems to leave as an exercise to the reader. And yes, they're in use in real companies at gigantic scales. (Indeed, Kerberos is central to Microsoft's technologies these days.) The example I used was only illustrative. SKSML allows for 2^64 keys per server, 2^64 servers per domain and 2^64 unique domains on the internet. The GlobalKeyID (GKID) of a key within a Symmetric Key Management System (SKMS) is defined to be a triple consisting of the concatenation of the unique domain ID, the server ID and the key ID (DID-SID-KID). So GKID's can range from 1-1-1 all the way upto (2^64-1)-(2^64-1)-(2^64-1); so it is fairly scalable. That said, Kerberos clearly has the benefit of 20+ years of research and use in the field. However, there are two fundamental differences between SKSML and Kerberos, IMHO: 1) The design goals for Kerberos were very different from SKSML. The former solves the problem of network-authentication in the face of insecure hosts/networks, while the latter focuses on long-term key management. That they both use very similiar concepts components to deliver quite different benefits to applications is testament to the strength and flexibility of the underlying components rather than to a weakness of SKSML. 2) AFAIK, Kerberos clients cannot deliver their stated benefit (network authentication) in the absence of the network or the Kerberos server. SKSML is designed to allow disconnected EKMI clients to continue providing cryptographic services to applications even in the absence of the network or the key-management server. However, it does require that the Symmetric Key Client Library (SKCL) have connected to the Symmetric Key Services (SKS) server at least once before it can use this capability. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Cat Okita wrote: ... or in other words, EKMI leaves all of the hard/impossible problems to be solved by somebody else. I'd have to agree with Ben that I'm not seeing the value add of an additional layer of complexity. I view EKMI as using the best tools the cryptographic community has to offer to solve specific business problems. As I stated in an earlier e-mail, one man's meat is another man's poison. What you see as additional layer of complexity is viewed as a layer of simplification by some people - no different from how one might view a self-starter in an automobile, as a layer of complexity over a crank-starter. That's an interesting presumption that you're making -- are you familiar with your audience? To the extent that anyone can claim familiarity with something as fickle and temporal as the needs of an audience, I believe I do (for the moment). I recognize that I cannot please everyone in any audience, and must therefore, do/say what what I believe is right for my customers. Only time will tell if I got it right - temporarily. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor [EMAIL PROTECTED] writes: That said, Kerberos clearly has the benefit of 20+ years of research and use in the field. However, there are two fundamental differences between SKSML and Kerberos, IMHO: 1) The design goals for Kerberos were very different from SKSML. The former solves the problem of network-authentication in the face of insecure hosts/networks, while the latter focuses on long-term key management. Well, kerberos does both, really. It also has the advantage that it is fully specified and integrates with GSSAPI. That they both use very similiar concepts components to deliver quite different benefits to applications is testament to the strength and flexibility of the underlying components rather than to a weakness of SKSML. 2) AFAIK, Kerberos clients cannot deliver their stated benefit (network authentication) in the absence of the network or the Kerberos server. It is generally hard to deliver network authentication without a network. That said, kerberos tickets can persist even in the face of disconnects, so once you've connected tickets can survive as long as you wish. SKSML is designed to allow disconnected EKMI clients to continue providing cryptographic services to applications even in the absence of the network or the key-management server. However, it does require that the Symmetric Key Client Library (SKCL) have connected to the Symmetric Key Services (SKS) server at least once before it can use this capability. That's no different from Kerberos, and kerberos works quite well already. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger wrote: That said, kerberos tickets can persist even in the face of disconnects, so once you've connected tickets can survive as long as you wish. But, can the tickets be used for anything useful when the network does not exist? I agree that when the network comes back, the ticket can pick up where it left off and continue providng its stated service until the ticket expires; but unless there are applications I'm unfamiliar with, Kerberos tickets are not very useful in the absence of a network. Yes, they can be used to authenticate to local services on the disconnected client, but what benefit does that provide? SKMS clients can continue to provide the capability they were designed for, even when the network is unavailable - it was a critical design goal. Yes, applications don't need a central key-management service to use cryptographic keys on a client; but the whole business purpose for SKMS is to have centralized policy-driven key-management, with the added benefit of secure, disconnected operations. If this comes back to Ben's original statement about it being just a key-escrow service, then so be it. But lets not dismiss the value standardization and abstraction of this capability provides - after all people didn't really need DBMS's 30 years ago because they could do all the data-management operations inside each application quite well, thank you! But, the true value of DBMS was to free up application developers, operations and business managers to deliver new levels of information services because they no longer had to deal with the arcane mechanics of data-management in unique ways inside each application, on each platform. What DBMS did for the abstraction and standardization of data-management, I anticipate SKMS doing for key-management. Those precise three groups of people - and now, including security and compliance officers - are slowly starting to discover that for themselves. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
With the caveat that I am reading mail in reverse order (i.e., panic-mode), I do have to say one thing and it isn't even to mount a stirring defense of Kerberos, which does not need defending anyhow... The design space for practical network security has always been: I'm OK You're OK The Internet is a problem A gathering storm of compromised machines, now variously estimated in the 30-70% range depending on with whom you are talking, means that the situation is now: I'm OK, I think I have to assume that you are 0wned The Internet might make this worse Put differently, network security has now come close to Spaf's famous line about netsec in the absence of host security being assured delivery of gold bars from a guy living in a cardboard box to a guy sleeping on a park bench. BTW, it is probably time to turn off your software's autoupdate feature. http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt Likely off-topic, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor [EMAIL PROTECTED] writes: Perry E. Metzger wrote: That said, kerberos tickets can persist even in the face of disconnects, so once you've connected tickets can survive as long as you wish. But, can the tickets be used for anything useful when the network does not exist? If you have a locally service that uses them, sure. In any case, a ticket gives you access to a crypto key, and you can use that for all sorts of things. SKMS clients can continue to provide the capability they were designed for, even when the network is unavailable - it was a critical design goal. Well, again, you can do the same thing with Kerberos, and Kerberos has the added advantage that there is a complete spec that fully handles all the details and is actually implemented and available off the shelf -- even built in to Windows. SKMS is vaporware that leaves all the hard parts of the specification out. If this comes back to Ben's original statement about it being just a key-escrow service, then so be it. But lets not dismiss the value standardization and abstraction of this capability provides I'm inclined to dismiss it, if only because you can do all of it with existing, implemented and fully specified tools with no added complexity. I actually have much larger reservations, but I think that alone eliminates the reason to consider it. - after all people didn't really need DBMS's 30 years ago because they could do all the data-management operations inside each application quite well, thank you! I think that comparing the advance SQL made with SKMS seems a bit unreasonable. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger wrote: Arshad Noor [EMAIL PROTECTED] writes: - after all people didn't really need DBMS's 30 years ago because they could do all the data-management operations inside each application quite well, thank you! I think that comparing the advance SQL made with SKMS seems a bit unreasonable. I think that Arshad's point here is an argument that externalising key management handling from normal application logic is a valid one but that it is also equally applicable to existing Kerberos environments. I don't think a point beyond externalisation is good was trying to be made here. Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
compromised hosts (was Re: Strength in Complexity?)
[EMAIL PROTECTED] writes: The design space for practical network security has always been: I'm OK You're OK The Internet is a problem A gathering storm of compromised machines, now variously estimated in the 30-70% range depending on with whom you are talking, means that the situation is now: I'm OK, I think I have to assume that you are 0wned The Internet might make this worse Put differently, network security has now come close to Spaf's famous line about netsec in the absence of host security being assured delivery of gold bars from a guy living in a cardboard box to a guy sleeping on a park bench. This is indeed a big new problem -- indeed, I'd say that how you deal with partially trusted people logged on to untrusted equipment is now the name of the game. BTW, it is probably time to turn off your software's autoupdate feature. http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt Likely off-topic, Not entirely. :) -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Tim Hudson [EMAIL PROTECTED] writes: I think that Arshad's point here is an argument that externalising key management handling from normal application logic is a valid one but that it is also equally applicable to existing Kerberos environments. I don't think a point beyond externalisation is good was trying to be made here. Well, that's not unreasonable. Of course, if you're looking for ways to add a layer so that application logic can be detached from authentication logic, GSSAPI is one answer. People may have varying opinions on GSSAPI, but it does have the merit of existing and being widely available. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger wrote: SKMS is vaporware that leaves all the hard parts of the specification out. An open-source implementation has been available for 2 years. A new version will be available next year that will implement the current OASIS draft and whatever useful comments the Public Review of the specification brings. I think that comparing the advance SQL made with SKMS seems a bit unreasonable. I was comparing the concept of data-management to key-management, which is a more appropriate analogy; there is no end-user language within an SKMS. WRT comparing SKMS to Kerberos, for 20+ years I've always seen Kerberos as a network-authentication protocol and perhaps it is my failing that I couldn't see the possibility of using a flat-head screwdriver in a Philips-head screw. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
[EMAIL PROTECTED] wrote: With the caveat that I am reading mail in reverse order (i.e., panic-mode), I do have to say one thing and it isn't even to mount a stirring defense of Kerberos, which does not need defending anyhow... The design space for practical network security has always been: I'm OK You're OK The Internet is a problem A gathering storm of compromised machines, now variously estimated in the 30-70% range depending on with whom you are talking, means that the situation is now: I'm OK, I think I have to assume that you are 0wned The Internet might make this worse Put differently, network security has now come close to Spaf's famous line about netsec in the absence of host security being assured delivery of gold bars from a guy living in a cardboard box to a guy sleeping on a park bench. BTW the original quote seems to be: Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police. -- http://homes.cerias.purdue.edu/~spaf/quotes.html /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: Strength in Complexity?
So, an executive summary of your responses appears to be EKMI leaves all the hard/impossible problems to be solved by components that are out of scope. As such, I'm not seeing much value. Anyway... Arshad Noor wrote: Ben Laurie wrote: OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? One man's meat :-). (I don't necessarily view this as a problem Ben. I've built up a career and a small business in the last 9 years doing just that.) Nevertheless, to answer the question, the PKI deployment is not part of the SKSML prtocol (other than the WSS header that carries the XML Signature and/or XML Encryption of the SOAP Body), but it is part of an EKMI. (EKMI = PKI + SKMS). A company deploying an EKMI must have, or must build a PKI and deploy the client/server certificates separately from the SKMS. While this might be viewed as a problem for some/many companies in the short-term, I fully anticipate that vendor implementations of SKMS will integrate with PKI software to manage this process seamlessly in the future. PKI out of scope... I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. Which is why we are recommending that SKMS clients use hardware based modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the Private Key used by SKMS client to decrypt the symmetric keys. While even these can be attacked, the problem is now in a different domain than the SKSML protocol. ...impossibility of solving DRM problem out of scope... EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? What I meant to say is that EKMI's goal is to protect the data and not the network. ...goals the same as pretty much all cryptographic protocols... If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. I'm not sure which verification process you're referring to. No, this is not security theater. EKMI does not guarantee anything, nor does it promise unbreakable anything. Everything in EKMI is a choice. You get to choose the strength of your keys, your PKI, your policies, your procedures and your implementation. All we're offering is a tool that does something specific to the extent that the specifications and the technology allows. Nothing more, nothing less. If you - as a cryptographer - say that AES-156 will do X under these conditions, then EKMI will support X under those conditions. EKMI only adds the ability to manage a large number of keys centrally, and to ease many of the administrative burdens we see that large-scale key-management can cause. Everything it does is constrained by the limitations of the underlying technology components, polices and practices. But you still have to make the choice. ...security out of scope and scope out of scope. Is there anything other than key escrow that's actually in scope? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Ben Laurie wrote: So, an executive summary of your responses appears to be EKMI leaves all the hard/impossible problems to be solved by components that are out of scope. A more optimistic way of putting this, Ben, is to state that EKMI allows domain-experts of underlying components to address the complex issues of their domain in ways that they deem best, while providing value on top of those components. I see no reason to reinvent any of the components - despite their imperfections - when they serve my purpose very well. The business goal here is not cryptographic elegance or perfection, but a solution to a problem without creating new vulnerabilities. As such, I'm not seeing much value. That may be because you are a cryptographer. If you were the CSO, an Operations Director, or an Application Developer in a company that had to manage encryption keys for 5,000 POS Terminals, 10,000 laptops, desktops and servers across multiple data-centers and 400 stores, you would see it very differently. Is there anything other than key escrow that's actually in scope? Yes. - The KeyUsePolicy element in SKSML tells conforming applications how to use the symmetric key, where to use it, when to use it, for what purpose, for how many transactions, etc. - The KeyCachePolicy element tells SKSML clients whether they may cache keys, and if they may, how many of them and for how long so that conforming applications can continue to use keys even when disconnected from the central key-management server. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Ben Laurie wrote: OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? One man's meat :-). (I don't necessarily view this as a problem Ben. I've built up a career and a small business in the last 9 years doing just that.) Nevertheless, to answer the question, the PKI deployment is not part of the SKSML prtocol (other than the WSS header that carries the XML Signature and/or XML Encryption of the SOAP Body), but it is part of an EKMI. (EKMI = PKI + SKMS). A company deploying an EKMI must have, or must build a PKI and deploy the client/server certificates separately from the SKMS. While this might be viewed as a problem for some/many companies in the short-term, I fully anticipate that vendor implementations of SKMS will integrate with PKI software to manage this process seamlessly in the future. I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. Which is why we are recommending that SKMS clients use hardware based modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the Private Key used by SKMS client to decrypt the symmetric keys. While even these can be attacked, the problem is now in a different domain than the SKSML protocol. EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? What I meant to say is that EKMI's goal is to protect the data and not the network. If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. I'm not sure which verification process you're referring to. No, this is not security theater. EKMI does not guarantee anything, nor does it promise unbreakable anything. Everything in EKMI is a choice. You get to choose the strength of your keys, your PKI, your policies, your procedures and your implementation. All we're offering is a tool that does something specific to the extent that the specifications and the technology allows. Nothing more, nothing less. If you - as a cryptographer - say that AES-156 will do X under these conditions, then EKMI will support X under those conditions. EKMI only adds the ability to manage a large number of keys centrally, and to ease many of the administrative burdens we see that large-scale key-management can cause. Everything it does is constrained by the limitations of the underlying technology components, polices and practices. But you still have to make the choice. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor wrote: Ben Laurie wrote: Arshad Noor wrote: I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. I find the question difficult to understand. Before I could even begin to answer, you'd have to define what proper key management actually is. I consider KM to be the discipline of defining policy and establishing procedures infrastructure for the generation, use, escrow, recovery and destruction of cryptographic keys, in conformance with the defined policies. Then I would agree that a protocol alone could not achieve all of this, though obviously it is possible to design a protocol that makes it impossible. That said, EKMI (from my brief reading) has a view of key management that is only proper in quite constrained circumstances. In particular, keys are available to participants other than those who are communicating, which is general considered to be a very bad idea. I'm not sure I'm following your comment here, Ben. Did some word get left out? In EKMI, keys are available only to those who are known to the central Symmetric Key Services (SKS) server, and who are authorized to receive keys. The knowledge comes from entries in the SKS server about the clients and their digital certificates. The authorization comes from ACLs and from policies that apply to the client. OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? So, yes, EKMIs are designed for constrained environments. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; Well. You said centralized server. Many cryptographic systems don't have one of those. I realizecd that two years ago when I started defining the architecture for EKMI and the software to implement it. It was the only logical way of addressing the business problem of managing encryption keys for five different platforms/applications that needed to share ciphertext on a daily basis across hundreds of locations and thousands of POS registers. I'd be very surprised if it were the _only_ logical way to do it. But that aside, my point stands: these characteristics are not shared by all cryptographic systems. In fact, I'd say that all of them are not shared by most cryptographic systems. Also, the idea of a client library enforcing policy is DRM all over again. Which, as we all know, will never work. You make an interesting point here. While, conceptually, EKMI and DRM share similar designs, I believe the reasons for DRM's failure has more to do with philosophy than with technology. But that's a different debate. I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. The fact that the attackers is highly motivated because of the objectionable nature of DRM does not seem to differ much from your system, though in your case the motivator will presumably be profit. P.S. Companies deploying an EKMI must have an external process in place to ensure their applications are using verified libraries on the client devices, so their polices are not subverted. Ha ha. Like that's going to work. Even if we assume that libraries are verified (fat chance, IMO), how are you going to stop, for example, cut'n'paste? Employees reading things out over the phone? Bugs? Etc. EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? As such, it will merely be a tool in the evolution towards more secure systems - how people use the tool is up to them. If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Florian Weimer [EMAIL PROTECTED] writes: Let me rephrase my remark: The trust anchor is conceptually separate from a root CA certificate. Conceptually yes, in the same way that the Soviet constitition was conceptually quite liberal and protective of individual rights. In practice, no. Look at your browser, email app, ... to see how it's reaally done. Nothing in that section gives you permission to ignore extensions on the CA certificate (skipping the first entry in the certification path). In addition, the trust anchor cannot be used directly to verify certificates issued by the CA because the subject DN does not match. Ergo, the extensions on the CA certificate are still in force. I think people might be getting a bit tired of this discussion of PKI quirks so how about the following: you go to the X.509 standards folks and convince them that your interpretation of the spec as given above is the correct one. Once that's done, we can continue. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor wrote: Florian Weimer wrote: * Arshad Noor: http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 On a more serious note, I think the criticism probably refers to the fact that SKSML does not cryptopgrahically enforce proper key management. If a participant turns bad (for instance, by storing key material longer than permitted by the protocol), there's nothing in the protocol that stops them. Thank you for your comment, Florian. I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. Any examples you can cite where this has been done, would be very helpful. I find the question difficult to understand. Before I could even begin to answer, you'd have to define what proper key management actually is. That said, EKMI (from my brief reading) has a view of key management that is only proper in quite constrained circumstances. In particular, keys are available to participants other than those who are communicating, which is general considered to be a very bad idea. This is fine if you are a corporation wanting to achieve escrow, of course. Though that can be done without requiring a central server to remember all the keys, of course. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; In some form or another, don't all cryptographic systems follow a similar paradigm? Well. You said centralized server. Many cryptographic systems don't have one of those. Also, the idea of a client library enforcing policy is DRM all over again. Which, as we all know, will never work. So, in short: no, they don't. Arshad Noor StrongAuth, Inc. P.S. Companies deploying an EKMI must have an external process in place to ensure their applications are using verified libraries on the client devices, so their polices are not subverted. Ha ha. Like that's going to work. Even if we assume that libraries are verified (fat chance, IMO), how are you going to stop, for example, cut'n'paste? Employees reading things out over the phone? Bugs? Etc. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Ben Laurie wrote: Arshad Noor wrote: I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. I find the question difficult to understand. Before I could even begin to answer, you'd have to define what proper key management actually is. I consider KM to be the discipline of defining policy and establishing procedures infrastructure for the generation, use, escrow, recovery and destruction of cryptographic keys, in conformance with the defined policies. That said, EKMI (from my brief reading) has a view of key management that is only proper in quite constrained circumstances. In particular, keys are available to participants other than those who are communicating, which is general considered to be a very bad idea. I'm not sure I'm following your comment here, Ben. Did some word get left out? In EKMI, keys are available only to those who are known to the central Symmetric Key Services (SKS) server, and who are authorized to receive keys. The knowledge comes from entries in the SKS server about the clients and their digital certificates. The authorization comes from ACLs and from policies that apply to the client. So, yes, EKMIs are designed for constrained environments. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; Well. You said centralized server. Many cryptographic systems don't have one of those. I realizecd that two years ago when I started defining the architecture for EKMI and the software to implement it. It was the only logical way of addressing the business problem of managing encryption keys for five different platforms/applications that needed to share ciphertext on a daily basis across hundreds of locations and thousands of POS registers. Also, the idea of a client library enforcing policy is DRM all over again. Which, as we all know, will never work. You make an interesting point here. While, conceptually, EKMI and DRM share similar designs, I believe the reasons for DRM's failure has more to do with philosophy than with technology. But that's a different debate. P.S. Companies deploying an EKMI must have an external process in place to ensure their applications are using verified libraries on the client devices, so their polices are not subverted. Ha ha. Like that's going to work. Even if we assume that libraries are verified (fat chance, IMO), how are you going to stop, for example, cut'n'paste? Employees reading things out over the phone? Bugs? Etc. EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. As such, it will merely be a tool in the evolution towards more secure systems - how people use the tool is up to them. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Arshad Noor: I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. Any examples you can cite where this has been done, would be very helpful. As far as I understand it, you don't actually change protocols, which means that there's likely no way around this problem. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; In some form or another, don't all cryptographic systems follow a similar paradigm? No, there are things like digital cash and mental poker which do not work with a trusted third party. I think it's even possible to compute RSA signatures from a split private key in a way that is secure against byzantine failure (IOW, a certain number of key holders needs to cooperate to forge a signature or recover the private key). There's also quite a bit of research on operations on encrypted databases. Of course, you cannot actually run an ordinary web shop on top of such protocols because interfaces to the public and to the processors are essentially fixed. Cryptographically securing the middle end seems rather pointless to me because the public-facing front end is the component that causes most of the trouble. (And I'm not fully convinced that more encryption is the answer to that.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Arshad Noor: The author of an article that appeared in InformationWeek this week (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI): http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 states the following: There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into. First of all, a simple SKSML request for a symmetric key is a whopping 77 lines of SOAPWSS/whatever XML; the server response is 62 lines even without the container. If this is not enough to make every complexity fanboy happy, I don't know what can do the trick. On a more serious note, I think the criticism probably refers to the fact that SKSML does not cryptopgrahically enforce proper key management. If a participant turns bad (for instance, by storing key material longer than permitted by the protocol), there's nothing in the protocol that stops them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Florian Weimer [EMAIL PROTECTED] writes: * Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? Yup. The app is supposed to read the cert, parse and process the extensions, and then throw them away. The text from the spec is: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Rendered into English, that says take the pubic key, owner name, and validity period, and ignore everything else in the cert. To pre-empt the inevitable yes, but it doesn't explicitly say you can't process the extensions if you want to: It also doesn't say you can't reformat the user's hard drive when you see a cert, but the intent is that you don't do anything not explicitly listed in the text above. One of the known problems with this is that any cert that's marked as trusted now becomes a root CA cert because of the requirement to ignore the fact that it isn't a root CA cert. Luckily no sane implementation pays any attention to this nonsense :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Peter Gutmann: Florian Weimer [EMAIL PROTECTED] writes: * Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? Yup. The app is supposed to read the cert, parse and process the extensions, and then throw them away. The text from the spec is: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Rendered into English, that says take the pubic key, owner name, and validity period, and ignore everything else in the cert. Let me rephrase my remark: The trust anchor is conceptually separate from a root CA certificate. It is only used to validate it the CA certificate. Nothing in that section gives you permission to ignore extensions on the CA certificate (skipping the first entry in the certification path). In addition, the trust anchor cannot be used directly to verify certificates issued by the CA because the subject DN does not match. Ergo, the extensions on the CA certificate are still in force. Luckily no sane implementation pays any attention to this nonsense :-). I think your interpretation actually leads to a non-compliant implementation. Obviously, wording of that section could be less confusing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Florian Weimer wrote: * Arshad Noor: http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 On a more serious note, I think the criticism probably refers to the fact that SKSML does not cryptopgrahically enforce proper key management. If a participant turns bad (for instance, by storing key material longer than permitted by the protocol), there's nothing in the protocol that stops them. Thank you for your comment, Florian. I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. Any examples you can cite where this has been done, would be very helpful. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; In some form or another, don't all cryptographic systems follow a similar paradigm? Arshad Noor StrongAuth, Inc. P.S. Companies deploying an EKMI must have an external process in place to ensure their applications are using verified libraries on the client devices, so their polices are not subverted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Peter Gutmann wrote: Pat Farrell [EMAIL PROTECTED] writes: At CyberCash, where we had real RSA/DES in the system, we found that users want convenience, not security I think that's phrasing it a bit badly, it'd be better put as without usability, you won't have users (see the Tor paper Challenges in deploying low-latency anonymity for more thoughts on this). I don't think we are disagreeing much, but the essence of the CyberCash law is that user's only focus is on convenience. If you give them a choice, any and all bumps in the road to ease of use cause rejection. I'm not trying to argue that 12+ years ago we had great usability. The world's expectations have evolved a lot since then. But we put a lot of engineering into usability. And it was not enough. I believe that its not users will accept some glitches to get security Rather, users only care about usability/convenience. It has to be trivial to use first. Cite Twitter, blogs, etc. The key message to take away is that when we pros design systems, at least for mass markets, the users will tolerate nothing except convenience. Pat -- Pat Farrell http://www.pfarrell.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger [EMAIL PROTECTED] writes: The problem, Peter, is that people who don't know you may mistake your sarcasm for agreement with misconception in the article Arshad quoted. What, me, sarcastic? Never! The point is not that fools (often including us) haven't built monstrous ziggurats that failed. The point is that no one rational should *SEEK* to make a protocol into monstrous ziggurat on the basis that this will improve security Sure, any rational designer, working by themselves, will (hopefully) create a simple, easy-to-analyse protocol. The problem seems to occur once you get committees involved (although I've seen some one-person-designed protocols that can match the output of any standards committee :-). So there's a difference between what should happen in an ideal world and what happens in practice. People will quite easily build monstrous ziggurats one mud-brick at a time, as any number of security protocols aptly demonstrate. They're not built because someone thinks they'll be more secure that way, but because the delegate from IBM suggested that we need this, and the delegate from MS insisted on having that, and the delegate from Verisign required the other. (Actually even that doesn't really explain something like IKE... :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
At 8:28 PM -0400 7/1/08, Perry E. Metzger wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: Perry E. Metzger [EMAIL PROTECTED] writes: No. In fact, it is about as far from the truth as I've ever seen. No real expert would choose to deliberately make a protocol more complicated. IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and I can provide a list as long as your arm. Protocol designers *love* complexity. The more complex and awkward they can make a protocol, the better it has to be. The problem, Peter, is that people who don't know you may mistake your sarcasm for agreement with misconception in the article Arshad quoted. The quote from the article was: There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into. It jumps from components to protocols. In general, encryption purists like simpler algorithms. OTOH, when encryption purists get involved in protocol design, the protocols usually become complex to the point of opacity. So, I agree with Peter that that article is probably correct about protocols. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
[EMAIL PROTECTED] (Peter Gutmann) writes: (Actually even that doesn't really explain something like IKE... :-). Having been peripherally involved in the causation change for IKE, let me confess that it was caused by human stupidity destroying the alternatives. The author of the much cleaner spec asserted copyright and control over it, and fearing lawsuits, people turned to the the remaining alternative. A number of us were all to blame for the situation. I will point out that the I Dislike IKE pins were not rare at meetings. Most people understood the situation as it happened. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
On Wed, Jul 02, 2008 at 07:25:36AM -0400, Perry E. Metzger wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: (Actually even that doesn't really explain something like IKE... :-). Having been peripherally involved in the causation change for IKE, let me confess that it was caused by human stupidity destroying the alternatives. The author of the much cleaner spec asserted copyright and control over it, and fearing lawsuits, people turned to the the remaining alternative. A number of us were all to blame for the situation. Out of curiosity, was this other spec Photuris? -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
On Wed, 2 Jul 2008, Peter Gutmann wrote: | Date: Wed, 02 Jul 2008 12:08:18 +1200 | From: Peter Gutmann [EMAIL PROTECTED] | To: [EMAIL PROTECTED], [EMAIL PROTECTED] | Cc: cryptography@metzdowd.com, [EMAIL PROTECTED] | Subject: Re: Strength in Complexity? | | Perry E. Metzger [EMAIL PROTECTED] writes: | | No. In fact, it is about as far from the truth as I've ever seen. | No real expert would choose to deliberately make a protocol more | complicated. | | IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and | I can provide a list as long as your arm. Protocol designers *love* | complexity. The more complex and awkward they can make a protocol, | the better it has to be. The cynical among us might rephrase that as: The more complex and awkward they can make a protocol, the better it will be at generating future consulting work. :-( (I don't think that applies to your list, where the root causes have more to do with design-by-committee and the consequent need to make everyone happy.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Jack Lloyd [EMAIL PROTECTED] writes: Having been peripherally involved in the causation change for IKE, let me confess that it was caused by human stupidity destroying the alternatives. The author of the much cleaner spec asserted copyright and control over it, and fearing lawsuits, people turned to the the remaining alternative. A number of us were all to blame for the situation. Out of curiosity, was this other spec Photuris? Sadly. That situation was long and complicated and I'd prefer not to go into it -- and I'd prefer actually if others didn't either, as it is much more about humans and non-security politics than it is about security or cryptography. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger wrote: Jack Lloyd [EMAIL PROTECTED] writes: Out of curiosity, was this other spec Photuris? Sadly. That situation was long and complicated and I'd prefer not to go into it -- and I'd prefer actually if others didn't either, as it is much more about humans and non-security politics than it is about security or cryptography. Isn't this true in general about nearly all security or cryptography? At CyberCash, where we had real RSA/DES in the system, we found that users want convenience, not security We built a paypal equivalent on top of our real security. Paypal made it look like they had security, but were convenient. Which company was sold for over a Billion? and which went bankrupt? Most attacks are more social engineering than breaking crypto. -- Pat Farrell http://www.pfarrell.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into. Let me first say that from the discussion here I now get the impression that this is how criticism of the EKMI spec is being characterized by its supporters. Their critics are encryption purists. I'm not sure what that means but it sounds kind of like people who believe in security over simplicity. An example where this concern might arise would be an overly simplistic protocol that used AES in ECB mode - simple by design, while the encryption purist advocated GCM, more difficult to break into but more complex. Now, I'm sure EKMI is not doing things this way but it is an example where simple would not look good to encryption purists. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Hal Finney wrote: An example where this concern might arise would be an overly simplistic protocol that used AES in ECB mode - simple by design, while the encryption purist advocated GCM, more difficult to break into but more complex. Now, I'm sure EKMI is not doing things this way but it is an example where simple would not look good to encryption purists. You are right, Hal. EKMI does not support AES in ECB mode. While this may not be acceptable to everyone, in SKSML version 1.0 we have chosen to currently support only the algorithms specified in XML Encryption (http://www.w3.org/TR/xmlenc-core/#sec-Algorithms): Block Encryption 1. REQUIRED TRIPLEDES http://www.w3.org/2001/04/xmlenc#tripledes-cbc 2. REQUIRED AES-128 http://www.w3.org/2001/04/xmlenc#aes128-cbc 3. REQUIRED AES-256 http://www.w3.org/2001/04/xmlenc#aes256-cbc 4. OPTIONAL AES-192 http://www.w3.org/2001/04/xmlenc#aes192-cbc Key Transport 1. REQUIRED RSA-v1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 2. REQUIRED RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p Message Authentication 1. RECOMMENDED XML Digital Signature http://www.w3.org/2000/09/xmldsig# Message Digest 1. REQUIRED SHA1 http://www.w3.org/2000/09/xmldsig#sha1 2. RECOMMENDED SHA256 http://www.w3.org/2001/04/xmlenc#sha256 3. OPTIONAL SHA512 http://www.w3.org/2001/04/xmlenc#sha512 Encoding 1. REQUIRED base64 http://www.w3.org/2000/09/xmldsig#base64 Even though SHA-384 does not appear on the XMLEnc digest list, we do support it too (the underlying crypto libraries support it, so it was no big deal to add it). We will also recommend that SHA1 not be used, along the timelines suggested by NIST, despite its appearance on this list. I understand that the W3C has started-up the XML Security WG again, and as these standards are updated, we will follow their work and support them in EKMI as appropriate. Should there be requests from the OASIS community that there be support for algorithms that are not in XMLEnc, the Technical Committee will discuss and vote on it. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Peter Gutmann) writes: (Actually even that doesn't really explain something like IKE... :-). Having been peripherally involved in the causation change for IKE, let me confess that it was caused by human stupidity destroying the alternatives. The reason why I was using IKE as an example is that it's a lot better-known than PKI. That is, most people on the list know in general terms that PKI is a mess, but probably only a few who have had to read and implement some of the RFCs (http://www.ietf.org/html.charters/pkix-charter.html) know just how incredibly *bad* it really is - it's a perpetual motion machine [0] of incomprehensible, contradictory, unimplementable, and often entirely nonsensical requirements [1] for which, once you get beyond the simplest mechanisms, the behaviour of any one implementation is more or less arbitrary as authors have to take guesses at what the authors of the spec (and the 15 other interfering specs in the same field) might have been thinking when they wrote it. And unlike the IKE bakeoffs there's no interop testing, so there's no way to tell whether any two implementations will ever treat the same (nontrivial) cert in the same manner. Unless you've had to implement PKI stuff it's difficult to convey the true horror of trying to make sense of those specs, which is why I've been using IKE as a better-known example. If you're an IKE fan then mentally replace all occurrences with PKI :-). Peter. [0] Don't like some way of doing things? Wait six months, three more RFCs will be along to provide different (generally incompatible) interpretations. [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? More amusingly, if you mark a non-CA cert as trusted then the requirement to ignore the extensions means that it can act as a trusted CA root certificate (with the same rights as, say, Verisign's root certs) since the not-a-CA flags has to be ignored. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Peter Gutmann wrote: For most crypto protocols, usability is job #8,107, right after did we get the punctuation right in the footnotes for the third appendix?. Usability disasters such as DNSSEC are more common than strictly cryptographic disasters such as wifi. DNSSEC is near impossible to use correctly end to end. Usually a cryptographic system is very difficult to use correctly, or to use incorrectly - as for example various VPN products. Sometimes a cryptographic system is easy to use incorrectly, difficult to use correctly, for example https and pretty much everything built on top of tls-ssl (old flame, never resolved, as to whether this is an inherent design flaw in the very concept of a cryptographic layer and any product that uses layering to factorize out the cryptographic code) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Pat Farrell [EMAIL PROTECTED] writes: At CyberCash, where we had real RSA/DES in the system, we found that users want convenience, not security I think that's phrasing it a bit badly, it'd be better put as without usability, you won't have users (see the Tor paper Challenges in deploying low-latency anonymity for more thoughts on this). This is why Skype is the dominant internet phone protocol and every attempt at building encrypted VoIP phones in the past ten years or so (anyone else here remember brew-a-stu?) has languished among a small set of crypto geeks. As Ian Grigg put it on his blog a few years ago, It took longer to do the setting up of some security options [in other software] than it takes to download, install, and initiate an encrypted VoIP call over Skype with someone who has never used Skype before. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Strength in Complexity?
The author of an article that appeared in InformationWeek this week (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI): http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 states the following: There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into. In light of the recent discussions about experts in cryptography, I thought I'd ask this forum to comment on the above author's statement: is this true? Do cryptography experts deliberately choose complexity over simplicity when the latter might provide the same strength of protection? Since I do not consider myself a cryptography expert, and have instinctively preferred simpler - but strong - technical solutions, have my instincts been wrong all along? TIA. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor [EMAIL PROTECTED] writes: In light of the recent discussions about experts in cryptography, I thought I'd ask this forum to comment on the above author's statement: is this true? Do cryptography experts deliberately choose complexity over simplicity when the latter might provide the same strength of protection? It's true to some extent. For most crypto protocols, usability is job #8,107, right after did we get the punctuation right in the footnotes for the third appendix?. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Perry E. Metzger [EMAIL PROTECTED] writes: No. In fact, it is about as far from the truth as I've ever seen. No real expert would choose to deliberately make a protocol more complicated. IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and I can provide a list as long as your arm. Protocol designers *love* complexity. The more complex and awkward they can make a protocol, the better it has to be. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Steven M. Bellovin wrote: I did see one possible red flag in the article: the key server verifies the client request, then encrypts, digitally signs, and escrows the key in a database. Escrowed keys are potentially *very* dangerous, but without knowing just what's being stored and how it's being protected, I can't say more. I appreciate the affirmation from Perry and Steven (so far) that I'm not off-base wrt designing security with simplicity in mind. I will confirm that security has taken precedence over simplicity where it was necessary to make a trade-off and where security was the primary goal. To respond to your concern, Steven, the escrowed symmetric keys are encrypted using a Public Key from an asymmetric key-pair (the recommended key-size is 2048-4096 bits RSA). The Private Key of the RSA key-pair capable of decrypting the escrowed keys is recommended to be generated and stored on a FIPS 140-2 Level 3 (or greater) certified HSM. For activating the HSM to use the Private Key by the SKMS service, it is recommended to use M of N FIPS-certified smartcards for strong authentication, so that no single individual is capable of accessing the Private Key (and consequently, any of the escrowed symmetric keys) on their own. (For those interested, an ACM paper on an earlier DRAFT version of the protocol/architecture of the SKSML protocol is available at: http://middleware.internet2.edu/idtrust/2008/papers/07-noor-ekmi.pdf I hope to inform this forum of the public availability of a more recent DRAFT of the protocol within the next two weeks, for review and comments. We, on the OASIS committee will be grateful for any feedback we get from this forum). My understanding of cryptography, after spending 9 years deploying PKIs - large and small - is that it is necessary to use a combination of strong technology and procedures for effective security. Relying on just one component alone can lead to a breakdown in security (as my experience has shown me). Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
[EMAIL PROTECTED] (Peter Gutmann) writes: Perry E. Metzger [EMAIL PROTECTED] writes: No. In fact, it is about as far from the truth as I've ever seen. No real expert would choose to deliberately make a protocol more complicated. IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and I can provide a list as long as your arm. Protocol designers *love* complexity. The more complex and awkward they can make a protocol, the better it has to be. The problem, Peter, is that people who don't know you may mistake your sarcasm for agreement with misconception in the article Arshad quoted. Oh, and by the way, you missed half a dozen failed secure mail protocols, SET (the Wikipedia article for SET really needs to be changed from present to past tense), and 20 other easy examples. It is sort of like shooting fish in a barrel, isn't it? The point is not that fools (often including us) haven't built monstrous ziggurats that failed. The point is that no one rational should *SEEK* to make a protocol into monstrous ziggurat on the basis that this will improve security, and don't pretend you don't agree, because most of us know you better than that. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
