Re: browser vendors and CAs agreeing on high-assurance certificat es
On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >I don't see why not - the technical details actually matter. Since the >servers will all share a socket, on any normal architecture, they'll all >have access to everyone's private keys. So, what is gained by having >separate certs? I responded in private email: > With a POLA architecture, perhaps on a capability OS (dream, dream), > they might not share access to the private keys. However, given current > software, I grant your point. Ben responded that I should post my comments to the list. There are two scenarios I see as being viable for separating the private keys with a security barrier. One is the single machine case alluded to above. Here the private keys would be in separate security domains, and the common part of the web server, which listens on the socket, would read the initial data on the TCP connection, select the correct security domain, and "pass" the connection to that domain. While the common part could continue to examine all the data, those data would be encrypted, so the it would have the same access as any other untrusted node in the path. The other scenario involves a network switch which performs the function of the common code of the web server. It uses network address translation to forward the connection's packets to the back-end computer with the correct private key. Here the keys are protected by being kept on separate computers. Both approaches allow a web hosting ISP to protect its customers from each other. This mutual protection is much the same requirement as existed in the time-sharing systems KeyKOS was designed to support. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
> And long before Quantum Computers become strong enough to crack > 2048-bit public key algorithms at a price that makes the > KGB want to waste its resources on you, there'll be > more convenient ways to blackbag machines, whether it's > including extra features in the OS through the audio CD player > or putting a video camera in your ceiling. Or rubber hoses, or indefinite detetion until you voluntarily comply with requests for keys, or seizure of business assets resulting in business failure even if no charges are ever filed, or ... - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
i'm working on a one time pad based IPsec key daemon with a similar purpose to what you describe. i'll be posting here for feedback when it's ready but the basic premise is that it provides strong ephemeral IPsec keying using one time pads previously exchanged between peers. as long as the pads are generated and secured properly[1] you don't need to care if $TLA has kept your IPsec traffic archives in their acres of computing machinery. likewise, if large qubit quantum computers suddenly become feasible or multi ring GCF gets really fast, you don't need to worry about past key exchanges (also archived) being compromised, as with pub key based ISAKMP implementations. Strikes me as a fairly silly project, except for the fun of coding it. There are a number of protocols like EKE, SPEKE, A-EKE, etc. that let you combine a shared password with public-key encryption for extra strength - a crude variant would be to encrypt your Diffie-Hellmann keyparts with AES for the key exchange, so there's nothing that can be conveniently attacked when the hypothetical Quantum Computer comes online. There's still a risk of compromising your keys if the KGB blackbags your machine, so you might want to change keys annually or monthly or whatever, but your OTPs are at risk just as a password would be. And long before Quantum Computers become strong enough to crack 2048-bit public key algorithms at a price that makes the KGB want to waste its resources on you, there'll be more convenient ways to blackbag machines, whether it's including extra features in the OS through the audio CD player or putting a video camera in your ceiling. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
