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: Randomness testing Was: On the randomness of DNS
On Aug 3, 2008, at 13:54, Alexander Klimov wrote: If your p-value is smaller than the significance level (say, 1%) you should repeat the test with different data and see if the test persistently fails or it was just a fluke. Or better still, make many tests and see if your p-values are uniformly distributed in (0,1). [Hint: decide on a p-value for that last equidistribution test *before* you compute that p-value.] Best, Stephan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Randomness testing Was: On the randomness of DNS
On Mon, 4 Aug 2008, Stephan Neuhaus wrote: Or better still, make many tests and see if your p-values are uniformly distributed in (0,1). [Hint: decide on a p-value for that last equidistribution test *before* you compute that p-value.] Of course, there are many tests for goodness of fit (Kolmogorov- Smirnov, chi-square, etc.) and also you can calculate for a given number of tests how many tests should have p-value below the significance level. And after making hundred tests you ask yourself what you gonna do once your test gives good uniformity, say p-value is 0.23, but the proportion is 0.95, while the minimum pass rate for 1% is 0.96. Only a bad statistician cannot justify any predefined answer :-) -- Regards, ASK - 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
