Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
There is a device that is similar to those characteristics: http://woudt.nl/epass-pgp/ http://www.financialcryptography.com/mt/archives/000201.html iang David Shaw wrote: On Tue, Sep 14, 2004 at 10:31:11AM +0200, Eugen Leitl wrote: I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and support crypto primitives (signing, cert generation). It doesn't have to be fast, but to support loading/copying of secrets in physically secure environments, and not generate nonextractable secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg. Since your environment includes GPG, then I think the OpenPGP smartcard meets pretty well what you are requesting. Combine it it with a USB smartcard reader, and the card becomes USB, too ;) http://www.silicon-trust.com/pdf/secure_8/48_ppc.pdf http://www.g10code.de/p-card.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
On Wed, Sep 15, 2004 at 04:30:54PM +0100, Ian Grigg wrote: > There is a device that is similar to those characteristics: > > http://woudt.nl/epass-pgp/ "If you loose or damage your token: you loose your private key and any data encrypted to it. Because the key is generated inside the token and cannot leave it, it is not possible to make a backup of the private key." is a knockout criterium, though. Also an interactive PIN entry for each interaction is a no-no, if the machine is in a rack at the host. H4x0rs may break in and sign a few stray blobs, but they won't be able to steal the private key itself. > http://www.financialcryptography.com/mt/archives/000201.html -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpjYj6c7OaaW.pgp Description: PGP signature
Forensic: Who gave this crypto talk?
Hi, I have again one of these special, strange, freaky questions. I'm still investigating some "unusual activities" in science and cryptography. There are some handwritten notes, they seem to be some kind of transcript of slides from a talk about cryptography. I need to find out when, where, and by whom that talk was given. These notes already existed in the end of 1997, so the talk must have been given 1997 or before. The talk is about cryptography and system design theory. It is about 'layers', such as physics, electrical engieering, boolean functions, boolean circuits, algebra of polynomial power series, operating system, automata theory. It mentions an "access & authentication description language for a modified secure unix-pw protocol", and comes to the conlusion that "crypto can act as a system science". Gus Simmons is mentioned several times, but this might not have been part of the talk but a personal annotation of the person who made the transcript. Does anyone know about such a talk? (The notes are available at http://www.danisch.de/tmp/discussion.pdf ) regards Hadmut - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
public-key: the wrong model for email?
[Perry: please use this version, if possible] Public-key cryptography burdens the recipient and puts the recipient in charge, while the sender is at the recipient's mercy. Is this the right model for email security? After all, the sender is the party at risk. To clarify, my comment is not that PKC is not useful for email. I believe it is, but not directly used as it is today. What I am saying is that the problem is key distribution. I want to separate the key distribution solution as directly done by PKC today (send the public-key) from a possible general solution for PKC key distribution that does not require sending the public-key. The point is that when PKC solves this problem directly, it solves it in a way that's useful for webservers (the webserver does not have to trust the client's certificate) but presents difficulties for email senders (the sender has to trust the recipient's certificate). Email use of PKC treats the recipient as a server. I think that what we need is a key distribution method for email (that can still use PKC and PKI) where, because the sender has all the risk, the sender defines how email is secured and delivered. The recipient should always be able to receive it, without too much burden or required previous work. For example, let's see how FedEx works. The sender chooses the service and the type of envelope to protect the message. The sender also chooses the instructions that must be followed before the envelope can be opened by the recipient. The recipient has no charge to pay for, or burden, in order to receive the envelope, and does not have to do anything before the envelope is sent. The recipient is able to verify the identity of the sender and, if so desired, refuse the envelope. The recipient can open the envelope if and only if the recipient is willing to follow the sender's instructions (e.g., providing name, address, date, signature). Yes, SSL and public-key encryption are and continue to be a success for web servers. However, the security model for protecting email with public-key cryptography seems to be backwards, technically and business wise. The sender, who is the party at risk, has to trust a lock provided by the recipient (his public-key) to protect her secrets (the message). If FedEx would provide message security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents. A better situation would arise if the lock (i.e., the envelope) would be controlled by the sender. Moreover, the recipient is not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock. In short, I find that public-key cryptography cannot solve the security issues of email when used as it is today and, most importantly, cannot provide the needed motivation for users, senders and recipients, to buy into it. It's not a matter of improvements in usability, better pricing or user education [1]. It simply does not work as it should work. That's also why, IMO, it does not take off. It is using the wrong mathematics for the problem. Does anyone know of any email system that would put the sender in charge? Comments? Cheers, Ed Gerck [1] Public-key cryptography gives the impression that email message security can be achieved quite simply. The public-key can be distributed at will, no need for secrecy, and anyone can receive private and secure messages. The same procedure being applied to each side, sender and receiver, both could immediately engage in private and secure communication. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
Eugen Leitl wrote: I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and support crypto primitives (signing, cert generation). It doesn't have to be fast, but to support loading/copying of secrets in physically secure environments, and not generate nonextractable secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg. Any suggestions? If I may put words in your mouth, you would require a server-side public key cryptography apparatus where the long-term private key value would be subject to utmost protection available, and the signature capability is nonetheless available to some "functional area" software on an general-purpose processor with less stringen protections. Hint: the software application where a security certificate is authorized is the Èfunctional areaÈ software. Presumably, some key management scheme must be provided so that once a "functional area" becomes suspicious, its usage of the private key can be rovoked through a key renewal, and the private key is not at stake. The disclosure of such system is at http://www.connotech.com/WIRCPATA.HTM. Be reassured that this was a preventive publication, so this design is in the public domain (and is, or should have been, prior art to US patent 6,671,804). Such server-side cryptographic hardware is currently under development. It should take the form of a 1U operational secure device and a separate key management console, the latter ensuring that no significant secret is ever stored on a personal computer. The application is not, however, certificate signing, as your post implies. I doubt that you will find products that fits your need as I expressed them. Perhaps with lower security, notably requiring that you trust the API design and implementation between the cryptographic hardware and the functional area. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: Actually, FreeSWAN's "Opportunistic Encryption" meant "if you've got IP traffic for somebody, see if they can do encryption with you and use it if you can." That seems to be the meaning of putting "Opportunistic" and "Encryption" together. Because Gilmore wanted to make sure encryption was always done securely, their implementation used a common PKI - DNSSEC and inverse DNS - which has the advantage that a security gateway can use it when all it knows is the IP address of the destination (which is typically the case), but the severe disadvantage that very few people have control over that DNS space and also that an IP address may belong to more than one domain. There's a significant policy question there - if you don't have a common PKI of some sort, is it worthwhile encrypting anyway, protecting against passive eavesdroppers but not MITM, or is that a false sense of security because the people who most need security are the people most likely to have a government annoyed enough at them to do the work of running a MITM attack? Encryption against passive eavesdroppers makes password-stealing and traffic analysis harder, so it's probably worth the risk, but that wasn't the choice that FreeSWAM made. Bill, you have a knack for putting this in context. Historically, it's possible to see why Gilmore went with the no-risk security, and reduced deployment of FreeSWAN by an order of magnitude or more. But, these days, it seems like a no-brainer: there is no such thing as an easily accessible trustworthy PKI. (I am recalled to mind the Hettingarian creed of "only financial guaruntees are trustworthy guaruntees...") And, the ones who have a government annoyed at them probably know they need special care I've not met a revolutionary that didn't know that the government is shooting at them. So the question is, how do we get FreeSWAN to use opportunistic cryptography, sans DNS? iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Peter Gutmann wrote: "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, Sounds good. Who wants to write it...? Since there seems to be at least some interest in this, I'll make a start on it. If anyone else wants to add their $0.03 to it [0], let me know. It occurs to me that a number of these ideas could be written up over time ... a wiki, anyone? I think it is high past time to start documenting crypto patterns. FWIW, on opportunistic cryptography (a la "SSH model") I wrote up a opportunistic draft paper here: http://iang.org/papers/spock.html (FTR, I've received substantial comments from TwanVDS and DigbytT.) iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
At 12:39 PM 9/15/2004, Ed Gerck wrote: > [1] Public-key cryptography gives the impression that email message security can > be achieved quite simply. The public-key can be distributed at will, no need for > secrecy, and anyone can receive private and secure messages. The same procedure > being applied to each side, sender and receiver, both could immediately engage > in private and secure communication. there are (at least) 2-3 characteristics of various public key systems 1) the public key doesn't have to be kept confidential as part of the distribution 2) you don't need a unique key for every unique security &/or business domain 3) other parties can attest to any bindings between the public key and other characteristics however, while the fact that public key secrecy isn't required (vis-a-vis secret keys) ... and possibly enables one or more of the mentioned characteristics, public key operation doesn't mandate all such characteristics be mandatory for the use of public keys. PGP allows that a relying party vet a public key with the key owner and/or vet the key with one or more others (web-of-trust) note that while public key alleviates the requirement that a key be distributed with secrecy ... it doesn't eliminate the requirement that the public key have some trust characteristic associated (i.e. secrecy will tend to include some trust, but elimination of secrecy doesn't eliminate the requirement for trust). so an infrastructure analogy to physical mail for public key is that public key becomes the trusted address for the recipient. in the physical world ... to send some mail ... you need a trusted mailing address for the recipient ... you need to have acquired that address in some manner and furthermore have some trust that it is the correct address. so lets assume that some number of equivalent mechanisms exist for public keys. it so happens that the encryption of the contents with the public key and the addressing of the contents with that same public key has some associated trusted infrastructure that delivers the package to the correct recipient. lets say that instead of having personal zip-codes and personal cell-phone numbers (that you take with you regardless of the service and/or physical location)... that can reach you regardless of where you happen to be in the world the "number" that can be guaranteed to reach you, also happens to have the characteristics of a public key. so public key mapping to entity infrastructures take on similar characteristics as personal (physical) mailing addresses and/or personal cell-phone numbers ... and then you have trusted infrastructures (usps, telephone companies, gov. posts) that can be relied on to make the connection to the appropriate recipient which then approximates a public key paradigm mapping to existing physical world paradigms. in the current physical world infrastructure, the publication &/or distribution of addresses are relatively low-cost (&/or free) operations with the infrastructures making their real money off the delivery ... as opposed to the publication. translated to the internet paradigm everybody has a public key (in much the same way that everybody can have a personal cellphone number that may reach them regardless of where they are in the world). the public key is registered in something like the domain name infrastructure which then is able to figure out how to find you in the world (in manner similar to how personal cellphone number can find you anywhere in the world). it isn't necessary that public key paradigms have to be the wrong model for email it is that the various existing economic models for making money off of public key infrastructures may be inconsistent with normal expected business operations. however, there is nothing intrinsic to public keys that mandate they are tied to existing public key infrastructure economic models. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
