Re: Sender and receiver non-repudiation
there is even simpler misappropriation ... that of virus on the machine ... how do you really know what your computer is doing. with paper signatures it is somewhat more clear-cut that the person signing a document ... is actually looking at the document they are signing. With digital signatures it becomes murkier ... how does somebody know that what they are looking at is the same thing that the computer is calculating a digital signature for. in retail situations, the burdon of proof is typically with the institutions to disproove any claims of forged signature. some of the draft digital signature laws (associated with certificates and certification authorities) started out trying to move that burden of proof to the consumer (i.e. most of the laws don't so much talk about non-repudiation per se ... they talk about disputes and who has the burden of proof and the standards for burden of proof). Some of these somewhat implied that a certificate was sufficient proof ... somewhat ignoring there could be thousands of foibles that might result in a digital signature not being what the key owner expected. business issues typically are associated with amount of risk ... aka how hard is it to defeat or compromise some system, how hard is it to show intent, etc. random refs: http://www.garlic.com/~lynn/2001g.html#25 Root Certificates http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000) http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup http://www.garlic.com/~lynn/2000f.html#64 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
On Tue, 3 Jul 2001 [EMAIL PROTECTED] wrote: there is even simpler misappropriation ... that of virus on the machine ... how do you really know what your computer is doing. The more control you have over your machine, and the environment, the more security you have. By hiding sensitive tasks into armored compartments you can push this way further, making it sufficiently secure for all practical purposes. with paper signatures it is somewhat more clear-cut that the person signing a document ... is actually looking at the document they are signing. With digital signatures it becomes murkier ... how does somebody But you are looking at a representation of a document, as rendered in the frame buffer. If you're worried about your machine being compromised, either use armored crypto hardware protected by clean protocols/interfaces, or an air gap protected machine containing only the barest OS essentials and crypto binaries, only transferring _passive_ (thanks to MS, it's essentially just plain ASCII) documents via sneakernet. For practical purposes you would use a smart card with a crypto processor on it. I personally think it would be interesting to see what can be done with polymer/OLED frame buffers printed directly on the top of a deep embedded, which does both video and crypto directly in the framebuffer compartment, and only talks via a fast packet switched network to the rest of the (wearable) computer. The less code and state is in there, the less potential for exploits. know that what they are looking at is the same thing that the computer is calculating a digital signature for. -- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
At 08:55 AM 7/3/01 -0700, [EMAIL PROTECTED] wrote: signing. With digital signatures it becomes murkier ... how does somebody know that what they are looking at is the same thing that the computer is calculating a digital signature for. Good point. There's no way without a trusted host somewhere. Imagine that you scanned the paper doc, inspected it visually, and digitally signed the image file. Even this is succeptible to a trojan that alters the display, alters what's printed, etc. If you do have a little trusted island, e.g., a java button on a ring you wear in the shower, or a PDA display you trust, you can often leverage this to make a trusted system. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Because current systems don't, to my knowledge, allow the creators of revocations to specify the reason(s) for revocation, I wonder if it would be better to rely on short-lived keys or certs which are renewed frequently during a person's membership or association with a group. Specifically, a revocation which does not distinguish between stopped working on the project because very busy at new job and left laptop with private key on public transit or discovered installed rootkit on machine storing unencrypted private key does not help people decide whether they can reasonably install old(er) distributions of a software package. If the package was signed by a person who is no longer participating as a builder/distributor, their key should not be current - but that doesn't mean that everything which has been signed with their key should be considered untrusted, as it would be in the case of a key compromise. In particular, consider the example of a person who's the last within a group to maintain a port/build/distribution on a hard-to-find platform, who then leaves the group - it may be difficult to find someone else to replace them, so new builds may not be available - but software which was once considered working and official shouldn't lose that status because of the change in group membership. Certainly, in the best of all possible worlds, everyone who installs software would have access to online CRL and CA resources, and we wouldn't need to think about whether or not a particular snapshot of reality is misleading in an especially optimistic or pessimistic way - but I believe we should not design (only) for that world. In the absence of semantic information about revocations, I think that expiration is a more appropriate model where no compromise is reasonably suspected, and that revocation is a more appropriate model where compromise is suspected or asserted. -- Greg Broiles [EMAIL PROTECTED] Organized crime is the price we pay for organization. -- Raymond Chandler - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Greg Broiles wrote: At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Because current systems don't, to my knowledge, allow the creators of revocations to specify the reason(s) for revocation, I wonder if it would be better to rely on short-lived keys or certs which are renewed frequently during a person's membership or association with a group. They do. GnuPG for example allows the user to choose between three main reasons, then to add a variable length string explaining the revocation. GnuPG output example: Please select the reason for the revocation: 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used 0 = Cancel (Probably you want to select 1 here) Your decision? 3 Enter an optional description; end it with an empty line: To our surprise Alex actually found a girlfriend! He no longer has time to work on this project. - VAB -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQE7QiqH+pIJc5kqSz8RAnJ3AKCpsqwpoB1oHvQv4/oMZJO6T/ZoKwCcCK8a f43nG9WYxKmZC9aaA+HQe4M= =D067 -END PGP SIGNATURE- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
all true it was part of the original point ... which was that much of the writing about security in conjunction with digital signatures all have to do with the responsibilities of certification authorities. However, it is possible to have a totally insecure infrastructure with the best certification authority along with their best policies and practices ... and still have a situation like the Emperor's new clothes. It is further possible to have a terrible secure infrastructure with secure chip-card, secure public/private keys, secure display, secure processes, along with trusted digital signatures ... and have absolutely no certificates. In lots of cases, you can treat certification authorities and certificates as totally orthogonal to the issues involved in trusting digital signatures. some random refs: http://www.garlic.com/~lynn/subtopic.html#fraud http://www.garlic.com/~lynn/subtopic.html#privacy http://www.garlic.com/~lynn/subtopic.html#sslcerts http://www.garlic.com/~lynn/subtopic.html#radius - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
IP: Celebrating the Fourth
--- begin forwarded text Date: Tue, 03 Jul 2001 21:02:48 -0400 To: [EMAIL PROTECTED] From: David Farber [EMAIL PROTECTED] Subject: IP: Celebrating the Fourth Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: David Farber [EMAIL PROTECTED] From: Whitfield Diffie [EMAIL PROTECTED] Tuesday 3 July 2001 at 17h45 In 1994, I sent the following message to the Cypherpunks From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Celebrating the 4th Date: Fri, 1 Jul 1994 at 13h01 On the 4th of July 1993, I walked out of my house and saw my neighbor's flag flying from the porch. I thought: ``I have no flag to fly; how shall I celebrate Independence Day?'' I went back inside and got Gunther's Casebook in Constitutional Law. At breakfast, I re-read the Constitution. A practice I recommend to all of you. I subsequently acquired online copies of the Constitution, and the even more appropriate Declaration of Independence from Danny Weitzner at EFF. Plain TeX copies are attached below, separated by a --- cut here --- line. (snip) (It seemed corny but I couldn't figure out how to improve on it since it was true.) Today the Constitution and the Declaration are readily available on the web and still worth reading once a year. Whit For archives see: http://www.interesting-people.org/ --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Oh? How? All you are suggesting is that the role key is held by a CA - well, who is that going to be, then? Unh, no. The same way the ASF determines who gets commit access could be teh same way the ASF determines who their CA will give release-signing keys to. The same way the ASF takes away someone's commit access is the same way they could update the CRL. All those key update, distribution, revocation, etc., stuff -- all those hard problems you said you want to automate -- go away. Recipients need only trust the Apache CA and its CRL. /r$ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Ben Laurie wrote: What this does not address is the common situation where the distribution gets signed by a different person each time (example: Apache). I had hoped the suggestion to identify a release master was sufficient. Thanks allot for your input. You make very good points, and I'll extend the next version of the HOWTO to cover this content. The obvious answer is use a role key. This doesn't work - how does one control who gets it? How is it distributed? What happens when a developer leaves the group (the role key has to be revoked and we start all over again?)? You have to build a whole organisation around the key, which is unlikely to happen at all, let alone be secure. In the case of small projects the role key could be shared, distributed hand to hand on a floppy or sent through PGP encrypted email. In the case of a large project like Apache, this obviously isn't possible. In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Role keys could be identified by signatures from a Master Key in a traditional model (much like PKI), through the posting of a list of authorized keys digitally signed with a master key, or in an anarchistic model (which it sounds to me is what you're describing) by signatures from other core developers. A threshhold could be established to consider a key officially certified for release, or a single signature could be acceptable. Maybe this is what you're looking for, a model of authorization like PKI except that it is based in the model of PGP's decentralized web of trust? Granted totally decentralized project like Apache cannot adopt the steps of the howto exactly as they are written with out altering their release model. However, such projects can make extremely beneficial use of third party testimonials, as the Apache Project does. Third party signatures on releases could be distributed with the release and the third parties performing those signatures could be the core developers. Core developers are obviously in a strong position to speak about authenticity and content. While the use of core developer signatures as third party testimonials would make such a group slightly more vulnerable to trojan horse attacks via faked key pairs, this level of increased vulnerability is not (in my opinion) very significant. The howto is just a guide. It is meant to be modified by individual projects as they see fit. I don't see the model you're describing as a barrier to adoption of a strong distribution model on the part of the apache project. In fact, the Apache Group seems to be using a strong distribution model for most of it's releases now. I modeled some of the content in the howto after the Apache practices. I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. Also, it would be nice to see the Apache group make its use of PGP signatures more prominent by posting a signature policy (if one is developed), and by linking to keys on a trusted keyserver as well as distributing them from the site so that new signatures are immediately available to people who wish to verify the testimonials of the core developers. Finally, perhaps the Apache Foundation would be willing to pick up the standards put forth in the HOWTO for files names of signatures? Everyone is pretty much doing their own thing right now - I tried to pick up the most popular stuff for standards I put forth in the howto. So, you pretty clearly have to do something that allows multiple keys to be used. It seems to me that the way to do this is to have tools that manage a set of keys which may change over time. The keys sign each other (the signatures would have to be tagged as signatures that allow a particular software distribution to be signed) and the user trusts the _set_ of keys, using the tools to check how keys get added and removed, ensuring that appropriate signatures are on new keys, and that revocations of old keys/signatures are checked. Organisations like the Apache Software Foundation can also have cross-checking between sets of keys to reduce the pain of building initial trust in a set of keys for a new piece of software from that organisation. [...] It is a non-trivial task, so if anyone wants to help with it, please let me know! I've been working on
Re: Crypographically Strong Software Distribution HOWTO
Rich Salz wrote: Oh? How? All you are suggesting is that the role key is held by a CA - well, who is that going to be, then? Unh, no. The same way the ASF determines who gets commit access could be teh same way the ASF determines who their CA will give release-signing keys to. The same way the ASF takes away someone's commit access is the same way they could update the CRL. All those key update, distribution, revocation, etc., stuff -- all those hard problems you said you want to automate -- go away. Recipients need only trust the Apache CA and its CRL. So how does this work in practice? How does an ASF subproject instruct the CA? How does one that's more divorced from any kind of formal structure? Seems to me you are introducing a monster security hole unless you somehow secure the instructions to the CA - and I can't see how to do that at all - at least, not without doing what I already proposed (and having the CA as the sole monitor of the correctness of the process). If Verisign can be spoofed into signing a Microsoft key, what hope for this model? None, IMO. Cheers, Ben. -- http://www.apache-ssl.org/ben.html 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: Crypographically Strong Software Distribution HOWTO
What this does not address is the common situation where the distribution gets signed by a different person each time (example: Apache). I've put some pretty serious thought into this problem and come to a few conclusions. The obvious answer is use a role key. All that work... when a conventional PKI will solve all the problems you listed. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Role keys could be identified by signatures from a Master Key in a traditional model (much like PKI), through the posting of a list of authorized keys digitally signed with a master key, or in an anarchistic model (which it sounds to me is what you're describing) by signatures from other core developers. A threshhold could be established to consider a key officially certified for release, or a single signature could be acceptable. Maybe this is what you're looking for, a model of authorization like PKI except that it is based in the model of PGP's decentralized web of trust? I am, but I don't like the idea of core developers - you are merely pushing back the place where you want a single key (or a well-defined set of keys) - and I claim that is not a realistic plan. You have to also allow the set of core developers to gradually change over time. Granted totally decentralized project like Apache cannot adopt the steps of the howto exactly as they are written with out altering their release model. However, such projects can make extremely beneficial use of third party testimonials, as the Apache Project does. Third party signatures on releases could be distributed with the release and the third parties performing those signatures could be the core developers. Core developers are obviously in a strong position to speak about authenticity and content. While the use of core developer signatures as third party testimonials would make such a group slightly more vulnerable to trojan horse attacks via faked key pairs, this level of increased vulnerability is not (in my opinion) very significant. Agreed. I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. I'm not sure I understand the significance of this request - why are version 4 keys better? Also, it would be nice to see the Apache group make its use of PGP signatures more prominent by posting a signature policy (if one is developed), and by linking to keys on a trusted keyserver as well as distributing them from the site so that new signatures are immediately available to people who wish to verify the testimonials of the core developers. Finally, perhaps the Apache Foundation would be willing to pick up the standards put forth in the HOWTO for files names of signatures? Everyone is pretty much doing their own thing right now - I tried to pick up the most popular stuff for standards I put forth in the howto. So, you pretty clearly have to do something that allows multiple keys to be used. It seems to me that the way to do this is to have tools that manage a set of keys which may change over time. The keys sign each other (the signatures would have to be tagged as signatures that allow a particular software distribution to be signed) and the user trusts the _set_ of keys, using the tools to check how keys get added and removed, ensuring that appropriate signatures are on new keys, and that revocations of old keys/signatures are checked. Organisations like the Apache Software Foundation can also have cross-checking between sets of keys to reduce the pain of building initial trust in a set of keys for a new piece of software from that organisation. [...] It is a non-trivial task, so if anyone wants to help with it, please let me know! I've been working on code similar to what you're describing as prototype perl scripts which I intend to port to patches against GnuPG. I'd be happy to help develop the tools necessary to allow Apache to embrace a strong distribution model more easily. Further, I would be greatfull to have an opportunity to contribute to a project such as Apache. Just let me know what you have and what you need. OK, looks like a new project is about to be born. Apache guys: does the ASF want to adopt this (given that the substrate is likely to be GPLed)? Or shall I set it up on my servers? Cheers, Ben. -- http://www.apache-ssl.org/ben.html 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
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Ben Laurie wrote: I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. I'm not sure I understand the significance of this request - why are version 4 keys better? Let me speak to version 3 PGP keys (version 2 keys are obvious afterwards). Version 3 keys create key fingerprints with MD5 which results in only a 32 byte hash as opposed to the 40 byte fingerprint produced by the use of SHA1 hash in openPGP version 4. In openPGP version 4, the keyid is the low 8 bytes of the SHA1 hash/fingerprint and the full keyid is the low 16 bytes of the hash/fingerprint. In version 3, there is no full keyid (16 byte ID) and the 8 bytes of the keyid are independent of the key fingerprint (It is the low 64bits of the public modulus of the RSA key). The use of MD5, and the failure to hash the full key material to generate the keyid makes version 3 keys significantly weaker (key id and fingerprint collisions, key content modifications) than version 4 keys. (Keep in mind that most PGP programs retrieve PGP keys from the keyservers, and specify keys in program operation, by the 8 byte keyid.) A quote from RFC2440 on Version 3 Keys: V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. So, everyone should generate all new keys with the version 4 format. I think it's a very good idea to attempt to migrate to the version 4 format if at all possible. Many people are still using version 2.6.x of PGP because of its source available status. This is obviously a bad thing. Those people should convert to GnuPG which runs on most platforms (including microsoft windows). Since most projects and developers do not yet have PGP keys and webs of trust set up, it is logical to have them use version 4. The projects which do have developers with version 2 and 3 keys usually don't have webs of trust set up which makes it of little cost to discard and replace the older keys. In the case of a project like Apache where there is an existing web of trust and a number of version 2 and 3 keys, there will be a significant cost to discard the older keys. The cost of the elimination of web of trust links is what I was referring to in the howto by 'good reason not to do so' when I said: I strongly suggest that you revoke any version 2 or version 3 public keys and replace them with version 4 keys unless you have good reason not to do so. However, due to the weaknesses in version 3 keys, it makes sense to attempt to start a migration in the Apache Project and the ASF to the openPGP version 4 format keys. Particularly with a conference coming up where developers will hopefully be able to get together and sign keys. Obviously, there has not been a compromise of the version 2 and version 3 formats that imparts an immediate need to revoke older keys and discard the links in the Apache Web of Trust. But, in my opinion there is still sufficient cause for migration to version 4. Apache members can have both a new version 4 replacement key and a well integrated version 2 or 3 key. Hopefully, the version 4 key will soon be well integrated and the version 2 or 3 key can be revoked. Until that time, a reciprocal signature between the old and new keys of an individual should provide for sufficient trust of new keys. It is just a suggestion. - VAB - --- V. Alex Brennen [EMAIL PROTECTED] [ http://www.cryptnet.net/people/vab/ ] [ http://www.advogato.org/person/vab/ ] C R Y P T O A N A R C H I S T -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQE7QhjX+pIJc5kqSz8RAiIYAKCBZmoTQY0ZsSiQ40WcEeZep9MI/wCeMLvo 1hSHI7Noy3/4lgZOVXzCRwI= =XZ13 -END PGP SIGNATURE- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
On Tue, 3 Jul 2001, Rich Salz wrote: So how does this work in practice? Who controls commit access? What mechanisms protect that? The same mechanisms that protect *the source* can be the same mechanisms that protect *the release.* I believe we have a greater need for protecting the releases with PGP than we have for protecting the source code. (For the releases it's close to the only line of defense; the source code can more easily be taken out of distribution and it's easier to verify). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
