Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote: Now that we've trashed non-repudiation ... just how is it different from authentication? In both cases, there is a clear technical meaning (though as with anything in mathematics, when you get right down to it, the details are complex and may be important): To produce an authenticator/non-repudiable signature, you must have access to the secret. There isn't, at this level, even any difference between the requirements for the two. Where we get into trouble is in attempting to bind the real world to the mathematics. In each case, the receiver wants to be able to say: lets say they are somewhat different threat models (but may have some partial overlap). it would be possible to give a dozen people the same passprhase and have some degree of confidence that only the permitted entities entitled to do something were authenticated. however, if one of them claimed that they didn't do some specific thing ... there would be difficult to differentiate between the different entities as to which entity had been authenticated at any specific time. some of the best practices security guidelines for authentication (like not sharing passwords) have more to do with non-repudiation ... than straight authentication. key-escrow can be considered mandatory for encryption keys under the non-single-point-of-failure and availability best practices. At the same time there may be mandatory requirements for NOT having key-escrow for authentication keys under non-repudiation best practices (even when the cryptographic technology is identical ... the issue of key-escrow policy is exactly opposite depending on whether the business use is encryption of authentication). a straight-forward authentication issue might be whether a particular message originated from a specific entity. That would not necessarily include the sense that the entity agreed with the terms and conditions described in the body of the message (say a financial transaction). This is somewhat akin to various EULA agreements that have people clicking on various buttons which is not an issue of authentication but of agreement; aka *repudiation* can include things that are outside the scope of authentication (not whether the message originated from me ... but do i fully agree with what is included in the body of the message). neither identification nor authentication by itself can necessarily include the concept of agreement. repudiation can include a number of items outside the sense of identification and authentication (like aggreement). -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
| Non-repudiation applied to digital signatures implies that the definition | states that only one person possibly had possession of the private signing | key and was conscious about the fact that it was used to sign something. There is absolutely *no* cryptographic or mathematical content to this definition! It could as well apply to key locks, to signatures on paper, or whatever. It's in no way a property of a cryptographic system, or of *any* system. Nor, as written, is there even any possible set of evidence that could be adduced to prove this: After all, someone might, just by chance, have guessed the private key. Granted, there are significant issues with non-repudiation - so significant that it probably isn't a very useful concept. But it there *is* some cryptographic content behind it! Otherwise, what are we to make, for example, of the various evolving signature key schemes that detect stolen keys? -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Jerrold Leichter wrote: Now that we've trashed non-repudiation ... Huh? Processes that can be conclusive are useful and do exist, I read here, in the legal domain. It may not be so clear how such processes can exist in the technical domain and that's why I'm posting ;-) just how is it different from authentication? Using an information theory model, it's clear that authentication needs one channel of information (e.g., the CA's public key, the password list) in addition to the signal (e.g., a signed message, a username/password entry). Authentication rests on the information channel being trusted (i.e., independently verifiable). In this model, non-repudiation is different because it needs at least one additional out-of-band signal (where authenticated absence of the signal is also effective). BTW, that's why digital signatures per se are repudiable -- there's no second, out-of-band signal. An additional technical difference is that authentication promotes strength of evidence while non-repudiation promotes lack of repudiation of evidence. The latter is intuitively recognized to be stronger because a single, effective denial of an act can rebuke any number of strong affirmations. This also means, intuitively, that another difference exists. Non-repudiation should be harder to accomplish than authentication (you want more, you need to pay more). However, to the extent that the process *can be* conclusive, non-repudiation may be worth it. Imagine the added costs, time and hassle (going back to a real-world comparison) if your bank would have to call you to confirm payment for every check you sign? This would be the case if paying a check could not be cast as a conclusive process for the bank (i.e., without the possibility of an irrebuttable presumption of payability). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
On Thu, 27 Nov 2003 11:30:45 -0500, Ian Grigg said: such keys to give them extra time to revoke the keys. However one addresss was from killfile.org and actually a mail-news gateway ... Was said key was being used to sign messages of some authentication importance? I don't know. art. Werner, if you come across any cases where people are incovenienced beyond the normal key code replacement issues, I'd hope you can share the anecdotes with us (suitably anonymised as appropriate)? Regarding this ElGamal sign bug, the only thing I heard of were a very few Debian developers who lost all their key signatures and have to start again gathering new signatures from their co-Debian developers. However there was no anger about this it sounds more like, oops, I shoot myself into my foot with my self-build secure thing. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
On Mon, 1 Dec 2003 11:20:10 -0800, Anton Stiglic said: From: Ralf Senderek [EMAIL PROTECTED] Maybe we can learn that code re-use is tricky in cryptography: indeed, if the signing function and encryption function did not use the same gen_k function, the author of the code would have done the optimization that But duplicates the lines of code and thus introduces another source of errors. Its aghrd to tell what ebtter. Given that the algorithms for signing and encryption are really different (compared to RSA) it might have been better to use separate source files for ElGamal-signing and ElGamal-encryption and don't view them as similar. g = 2 is safe but insecure for signatures... It's just simpler to have two distinct pairs of keys. Sure, that's what OpenPGP strongly suggests. However ElGamal signing stems from a time before OpenPGP when I tried to replace RSA by ElGamal and keeping most of the PGP2 format (rfc1991) in place. By the way, is the paper by Phong Q. Nguyen describing the vulnerability available somewhere? Or maybe someone could describe the cryptanalysis I don't know, please ask him. Phong dot Nguyen at ens.fr. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Ed Gerck wrote: Likewise, in a communication process, when repudiation of an act by a party is anticipated, some system security designers find it useful to define non-repudiation as a service that prevents the effective denial of an act. Thus, lawyers should not squirm when we feel the same need they feel -- to provide for processes that *can be* conclusive. The problem with this is that the squirms happen at many levels. It seems unlikely that we can provide for conclusive processes when it comes to mixing humans and tech and law. If we try, we end up with the Ross Anderson scenario - our work being trashed in front of the courts. Hence the need for a new framework. Talk of non- repudiation has gone to the extent of permitting law makers to create new presumptions which - I suggest - aren't going to help anyone. For example, the law that Pelle posted recently said one thing to me: no sane person wants to be caught dead using these things: Pelle wrote: The real meat of the matter is handled in Article 31 (Page 10). Guarantees derived from the acceptance of a Certificate: The subscriber, at the time of accepting a certificate, guarantees all the people of good faith to be free of fault, and his information contained within is correct, and that: 1. The authenticated electronic company/signature verified by means of this certificate, was created under his exclusive control. 2. No person has had access to the procedure of generation of the electronic signature. 3. The information contained in the certificate is true and corresponds to the provided one by this one to the certification organization. Is that for real? Would you recommend that to your mother? I wouldn't be embarrassed to predict that there will be no certificate systems in Panama that rely upon that law. I think aiming at conclusivity might be a noble goal for protocol designers and others lower down in the stack. When humans are involved, the emphasis should switch to reduction in costs: strength of evidence, fast surfacing of problems, sharing of information, crafting humans' part in the protocol. When I design financial systems, I generally think in these terms: what can I do to reduce the cost and frequency of disputes? I don't aim for any sort of conclusivity at any costs, because that can only be done by by setting up assumptions that are later easily broken by real life. Instead, I tend to examine the disputes that might occur and examine their highest costs. One of the easiest ways to deal with them is to cause them to occur frequently, and thus absorb them into the protocol. For example, a TCP connection breaks - did the packet get there or not? Conclusion: connections cannot be relied upon. Protocol response: use a datagram + request-reply + replay paradigm, and lose a lot of connections, deliberately. Conclusivity is achieved, at the cost of some efficiency. Another example - did the user sign the message? We can't show what the user did with the key. So, make the private key the agent, and give it the legal standing. Remove the human from the loop. Make lots of keys, and make the system psuedonymous. We can conclusively show that the private key signed the message, and that agent is to whom our contractual obligations are directed. Technical conclusivity is achieved, at the expense of removing humans. The dispute that occurs then is when humans enter the loop without fully understanding how they have delegated their rights to their software agent (a.k.a. private key). We don't deny his repudiating, we simply don't accept his standing - only the key has standing. Which brings us full circle to Panama :-) Except, we've done it on our own contract terms, not on the terms of the legislature, so we can craft it with appropriate limits rather than their irrebuttable presumptions. From this pov, the mistake that CAs make is to presume one key and one irrebuttable presumption. It's a capabilities thing; there should be a squillion keys, each with tightly controlled and surfaced rights. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Non-repudiation is really very simple in concept. The ability to prove to a third party that you (or someone else) was party to a transaction. There are a lot of problems regarding who the third party must be, what constitutes proof, etc., etc. In the English common-law system, this is applied in various ways and times. It all comes down to concepts of reasonableness, intent, care and so on. Can you say convince the judge or jury of your peers ? The same is true for authentication. John On 1/7/04 15:06, Anton Stiglic [EMAIL PROTECTED] wrote: - Original Message - From: Jerrold Leichter [EMAIL PROTECTED] Cc: Cryptography [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 7:14 AM Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)] Now that we've trashed non-repudiation ... just how is it different from authentication? I don't think the word authentication has the same problem as non-repudiation, but you do need to be careful how you define it. So here we are talking about entity authentication (as opposed to data authentication, the latter really has a unambiguous definition, at least I hope it does!). The way you should define entity authentication is by stating that it is a process of verifying that an entity possesses the authentication credentials associated to a user that entity claims to be. This entity might be the rightful user, or it might be someone who stole the credentials from the rightful user. If someone stole my ATM card and my PIN, he/she can successfully authenticate him/herself to an ATM and withdraw money. The word authenticate is appropriate in this last phrase. But I see that most definitions that have been collected here: http://www.garlic.com/~lynn/secgloss.htm#t523 are not careful about this. The thing about non-repudiation is that it is something that even most laws do not permit. See for example: http://www.firstmonday.dk/issues/issue5_8/mccullagh/ Non-repudiation applied to digital signatures implies that the definition states that only one person possibly had possession of the private signing key and was conscious about the fact that it was used to sign something. In most jurisdictions a person has the right to repudiate a signature (had-written or electronic), and thus non-repudiation does not work. People have the right to repudiate signatures since it might be the result of a forgery, fraud, the signer might have been drunk or something at the time of signing or forced to sign (like with a gun to his head).Repudiation is possible but non-repudiation is not. I know some people who use the term accountability instead of non-repudiation to express the property needed in certain systems (commercial infrastructures where users login and need to be accountable for their acts). This seems like a better term to be used in certain contexts, but I'm still thinking about it... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fun with CRLs!
/. is reporting this, anyone know the real story? Verisign Certificate Expiration Causes Multiple Problems Posted by michael on Thursday January 08, @03:46PM from the rot-at-the-root dept. We had to do a little sleuthing today. Many readers wrote in with problems that turned out to be related. A certificate which Verisign used for signing SSL certificates has expired. When applications which depend on that certificate try to make an SSL connection, they fail and try to access crl.verisign.com, the certificate revocation list server. This has effectively DOS'ed that site, and Verisign has now updated the DNS record for that address to include several non-routable addresses, reducing the load on their servers. Some applications affected include older Internet Explorer browsers, Java, and Norton Antivirus (which may manifest itself as Microsoft Word being very slow to start). Hope this helps a few people, and if you have other apps with problems, please post about them below. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The pirates of the 21st century (Translation)
This article recently ran in Die Zeit in Germany about Cyber Punks. I was ofcourse misquoted in the article, see my detraction about what was wrong: http://talk.org/archives/000193.html http://www.zeit.de/2003/50/Cypherpunks (original in German) http://talk.org/archives/000211.html (This Translation. CYBERSPACE The pirates of the 21st century Fighting against terror, police and secret services are establishing the surveillance state. But a group of computer geniuses is waging data war on authorities. A report from the world of encrypted messages. By Thomas Fischermann (translated by Veronika Leluschko) The art of power is the art of disappearing. (Paul Virilio) The computer in the ZEIT office just reported the reception of a town clerks e-mail. That man is an important informer for this story. One who has a certain reputation among the cryptographers, the inventor and user of electronic hiding and encrypting techniques. But that town clerks e-mail cannot simply be opened by clicking on it. It took a couple of minutes until the computer was accepted in the Lasseiz Faire City, an underground network, hiding deep underneath the surface of the internet, only to be entered with the right code words. On first sight, the Lasseiz Faire City doesnt look different from many other websites on the internet. One may send e-mails, post messages on a message board and visit chatrooms. But here, different form the usual internet, surfers can be assured of their anonymity. Nobody will intercept their messages. A series of techniques, some 25 years ago only available to secret services, encrypt electronic messages beyond recognition, let them dash around the globe as supposedly meaningless data dust, covering over all traces on their long journey. The town clerks message starts with aANQR1DBw04D/NSEz31qI+8QEADwytY, thats Cyphertext. A mathematically encrypted message, only to be read by its receiver. A few mouse clicks, a password, and finally something readable appears on the screen. Thomas, let me think about those questions. Il get back to you tomorrow. Welcome to the mysterious world of Cypherpunks! It was in May 1992, when Eric Hughes went to see his friend Tim May in Santa Cruz, California and ended up staying there for three days, chatting away. That time, Hughes was in his late 20s and a gifted mathematician from UC Berkeley; May was 10 years older, a former physicist at the Intel chip company, having retired a couple of years ago thanks to a huge shareholder package. It was obvious that the two scientists got along together well: they shared a similar taste for Western gear and cool sunglasses, a fascination for computer techniques and more than a healthy amount of paranoia. Most of all, they shared political convictions. Both regarded themselves associated with the libertarians, the supporters of an ultraliberal ideology, quite widely spread among the white American middle class. Libertarian Americans are facing the state in a particularly sceptical way, which concerns police as well as tax-collectors. Many of them would like to completely abolish states including their taxes and authorities and leave the power to the free market. That was the vigorous subject the two friends were discussing during their talk marathon that month of May. It wouldnt be worth mentioning if the duo hadnt been convinced of holding the key to their political dreams in their own hands. In fall 1992, May and Hughes created a loose association of like-minded people which lead to one of the most unusual and most obscure political movements of all times. They called themselves Cypherpunks, based on a science fiction style that had become popular around the end of the 19th century. They were a conglomeration of highly decorated scientists and dreamers, computer geniuses and political activists, lawyers and also criminals. They wanted to be rebels in cyberspace, those guys in sneakers and T-Shirts wanted to change the world, using their laptops as weapons. They would gather for fortuitous physical meetings, their Cypherpunk mailinglist would raise to one of the hottest internet debating places with almost 2000 subscribers. They wanted to be the technical elite, creating the infrastructure for a utopian, lawless cyberspace. And today, just 10 years later and after the terror attacks of 9/11, some of them see their hour come: as the last bastion against a society of surveillance. In the early 90s, the internet economy as we know it today, was still in its infancy. But among the technicians avantgarde Hughes and May frequented, visions of a a digital future had already quite progressed: People on the American west coast were already discussing how electronic mail would replace all paper mailings in and between companies, that all money and shares transfers should be moved from classical banking to cyberspace, that products such as music, movies and news should, one day,
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
I did a Google search on irrebuttable presumption and found a lot of interesting material. One research report on the State of Connecticut web site http://www.cga.state.ct.us/2003/olrdata/ph/rpt/2003-R-0422.htm says: The Connecticut Supreme Court and the U. S. Supreme Court have held that irrebuttable presumptions are unconstitutional when they are not necessarily or universally true and the state has reasonable alternative means of making the determination. The comment appears to apply to statutes and regulations (as opposed to contracts). Still the two tests mentioned seem very appropriate to a discussion of non-repudiation as used in cryptography. In deciding whether the existence of a verified signature should automatically lead to some real world action, we should consider both the adequacy of the technology and the nature of the application. So, for example, the military might adopt an irrebuttable presumption that a cryptographically signed order comes from the registered owner of a cryptographic key, because it has vetted all the technology employed, it can't tolerate delay, and is willing to impose a duty on a key holders to protect their key or suffer the consequences. On the other end of the scale, anti-spam software might accept a signature validated by a public key that is included in a user's white list as conclusive proof that the message should be transmitted to that user because the consequences of doing so with a forged message are so minute. In the case of ordinary consumer transactions, an irrebuttable presumption for public key signatures would not seem to pass muster. There are too many problems with the technology (its not just a question of protecting the private key, but also of insuring the the document actually signed is the one the user thought he was signing) and there are usually other forms of evidence (e.g. delivery records) to substantiate the transaction. This is apparently a very complex area of law. Another paper http://www.law.nyu.edu/clppt/program2003/readings/Franck.doc includes these quotes: Every writer of sufficient intelligence to appreciate the difficulties of the subject matter has approached the topic of presumptions with a sense of hopelessness and left it with a feeling of despair.5 Commenting on the law of presumptions, Judge Learned Hand has commented: Judges have mixed it up until nobody can tell what on earth it means.6 It sounds like the legal profession long ago recognized the difficulties the cryptographic community is now grappling with regard to non-repudiation. We should be very wary of assuming mathematical constructs naturally transform into the legal arena. Arnold Reinhold (who is not a lawyer) 5 Edmund M. Morgan, Presumptions, 12 Wash. L. Rev. 255, 255 (1937). 6 L. Hand, 18 ALI Proceedings 217-18 (1941). At 5:32 PM -0800 1/5/04, Ed Gerck wrote: In business, when repudiation of an act is anticipated we're reminded by Nicholas Bohm (whose clear thinking I know and appreciate for 6 years) that some lawyers find it useful to define irrebuttable presumptions -- a technique known to the law and capable of being instantiated in statute or contract. For example, a legal irrebuttable presumption can take the form of a bank check contract stating that a check (even though it can be *proven* a posteriori to be a forgery) is payable by the bank if the account holder did not notify the bank to repudiate the check *before* the check was presented to the bank for payment. The requirement can be seen an out-of-band signal from the account holder to the bank, which absence makes the check's payability an irrebuttable presumption by the bank. In this case, as long as the check's signature does not look like a (obvious) forgery and there is enough balance in the account, the bank has no liability to that customer in paying the check. Note also that the effectiveness of this method relies on an indirect proof -- the absence of a previous communication makes the check payable. Likewise, in a communication process, when repudiation of an act by a party is anticipated, some system security designers find it useful to define non-repudiation as a service that prevents the effective denial of an act. Thus, lawyers should not squirm when we feel the same need they feel -- to provide for processes that *can be* conclusive. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
