Re: Announcing httpsy://, a YURL scheme
[EMAIL PROTECTED] wrote: A YURL aware search engine may find multiple independent references to a YURL, thus giving you parallel reporting channels, and increasing trust. Of course, this method differs from the YURL method for trust. The parallel channel method assigns a trust value to a site by querying the YURL aware search engine. That's an extraordinarily good idea! It reminds me of the technique for determining banks SWIFT codes. It seems that the banks often don't really know themselves, so if you do a google search on the bank name and the word 'SWIFT' you will find lots of merchants that already quote it on the net! Now, one thing that could be done against such a situation is to poison the search engine with false URLs in advance of some mailing. This is relatively easy, although, will result in a lot of trails which might give indicators to the perp, so I'd count that as an expensive technique, and thus, the utility of the URL searching still remains high. YURLs are meant to be cached by the browser, I found that somewhere in the documents but do not recall where. The same obviously goes for Simon Josefsson's crypto-URLs, as mentioned by Trevoer Perrin. This is the really neat part, in that when we start to think of server authentication as a volume correlation problem - as expounded on by Mark Miller - rather than a one-supreme-quality problem, not only do we achieve sufficient security for most purposes, we do it with no more than the free net resources. And, it has the additional benefits of matching real life, and returning our Internet back to a no permission needed society. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
trust is not associative
The thread Announcing httpsy://, a YURL scheme has not dealt with the issues of *order of introduction* that, however, play a major role in terms of introduction and the development of trust. Let trust be the operation *. Suppose Jon trusts a CA and has his cert issued by that CA. After the cert was issued, the CA decides to trust Khadaffi and grants Khadaffi access and control to all of its issued certificate and CRL files, including Jon's of course -- which was already issued. This is represented by the result of (Jon*CA)*Khadaffi, (1) which is Ok because Jon trusts the CA before the CA trusts Khadaffi, and thus Jon gets his cert from that CA. This means that Jon accepts to be introduced by the CA. Suppose now that Jon learns beforehand that the CA trusts Khadaffi and all his data will be also know to Khadaffi if he decides to trust that CA and that Khadaffi could revoke his cert at will (e.g., simulating an error). Then, if Jon does not trust Khadaffi, he will not have his cert issued by that CA. This is now represented by the result of Jon*(CA*Khadaffi), (2) which is not Ok and Jon does not get his extrinsic cert from that CA. This means that Jon DOES NOT accept to be introduced by the CA. Of course, the result of (1) is not equal to (2). Trust depends on the event sequence. Trust is not associative. The same could be exemplified for competing businesses or competing countries, as I comment in the paper at http://www.mcg.org.br/cie.htm Or, you may trust your lawyer before you know he trusts your competitor but not after you know it. Of course, you may never know that an untrustworthy C of (A*B)*C exists (i.e., the confidence-leak problem) and you may forever trust Aldrich Ames! In short, a system that ignores that trust is not associative can make you rely on an otherwise unacceptable introduction. OTOH, a system that makes you rely on a single introduction is essentially setting you up for a single point of failure. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
Ed Gerck wrote: IF Alice is trusted by Bob to introduce ONLY authentic parties, yes. And that is the problem. Cryptography can't prevent Alice from telling lies about the web page that she showing to Bob. But it can prevent that Bob sees a page different than the one that Alice meant for him to see. Regards, Zooko http://zooko.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Looking for an N -out-of-M split algorithm
Hi, I remember reading (many years ago) a description on some web page somewhere of an algorithm by which an arbitrary file F could be split into M pieces, such that: (1) given any N pieces, F can be reconstructed precisely, and (2) given fewer than N pieces, it is impossible to determine even a single bit of information about F. Unfortunately, that was many years ago, and -- search as I might -- I haven't been able to find it on web now. Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. Jill [Moderator's note: look for Shamir Sharing -- the trick is just turning the secret into a polynomial of degree N so that with enough points you determine the polynomial uniquely and with too few you can't determine it. I'm pretty sure that Schneier and all of the other standard references explain this trick. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
Ian Grigg [EMAIL PROTECTED] writes: Perry E. Metzger wrote: 1) The YURL makes key management and replacement effectively impossible. Well, I would have said it suggests a different method. Instead of regimented, hierarchical and fixed key management - an idea of poor track record - What are you talking about? I'm talking about replacing keys. Almost every protocol out there lets you replace your keys at periodic intervals. Proper key hygiene dictates that you change your keys often enough that the security harm caused by disclosures or cracking is mitigated. Using this system, they're basically frozen forever because everyone on earth expects your HURL, er, YURL, to remain constant. Since when is proper key hygiene an idea of poor track record? the key management issue here is pushed back to the user client. It relies on browser assistance in caching, and correlation between many introducers. Our evidence in the long run is that users are extremely poor at handling security decisions like this. They don't understand the security implications of their actions. If the goal is to improve security over the existing system, especially because users tend to get spoofed, this doesn't succeed. In comparison to the CA regime, I think that's a poor point of comparison. It is like saying I don't like bad system A, so note how bad system B is so much better. There are fine ideas out there on how to handle this sort of thing that don't involve bad ideas at all -- I don't see why I should pick a bad way of doing things at all. 2) It leads to situations in which you have no way to know what sort of trust relationship you have for the documents you're looking at. I don't understand this. I do. You start by looking at document A. You click on it and end up at document B at another site. Then you click on it and end up at document C at yet another site. Before long, you're trusting documents that are very, very far from the original HURL, er, YURL you started with, and you have no idea what your trust relationship with them is at all. It is a recipe for serious trouble. Hmm, this claims to be www6.amazon.com and I somehow got there by an unknown sequence of clicks -- guess I'll give it my credit card number. SFS has the same problem -- by the time you've cd'ed into a few directories on a few file systems, you no longer have any idea what your trust path is at all. 3) It is impossible for people to determine that a YURL actually is what it claims it is, given that most people can't actually remember one hash, let alone large numbers of them, etc. Right. I don't think the YURL really meant for people to read the things. It could be better explained, the browser has to record and correlate the hashes. So in that sense, we end up with the worst part of the SSH model -- you get a message that a key has changed and you have no idea why or if it is legitimate so users ignore it. Not an improvement. Those are just some of the more obvious issues. I think it is a mistake to compare the URL+hash idea to some existing security model such as is purported by, for example, https. It really sits closer to raw HTTP - which is where most of the live usage is, and where all of the problems lie. That paragraph is completely incomprehensible to me. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
At 11:26 AM 7/16/2003 -0400, Perry E. Metzger wrote: Ian Grigg [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: A YURL aware search engine may find multiple independent references to a YURL, thus giving you parallel reporting channels, and increasing trust. Of course, this method differs from the YURL method for trust. The parallel channel method assigns a trust value to a site by querying the YURL aware search engine. That's an extraordinarily good idea! It reminds It seems to me to be more a bad idea, fully realized. I'll repeat: 1) The YURL makes key management and replacement effectively impossible. One approach: instead of putting the end-entity key's fingerprint in the URL, place the CA key's fingerprint. CryptoURLs have an x509_root_sha1 datatype for this purpose. Then ensure that the HTTPS server returns the CA's self-signed cert. The client hashes this to see if the fingerprint matches the cryptoURL, then validates the chain in the usual way. Now a compromise of the EE's key can be recovered from like normal. For example, the CA can issue short-lived certs, or the EE cert can have a CDP extension where CRLs are found. Compromise of the CA key is still a catastrophe, but it always was. The neat thing here is the EE can choose his own CA, based on the sole critieria that he believes it will remain secure, and will be rigorous in authenticating him. For example, I could choose my mom as my CA, since she's highly security-conscious and unlikely to certify anyone else as me. Or I could be my own CA, but split the CA key up into threshold shares and stow them in various safes and hiding places, and proactivize them periodically. The negative, security-wise, is that now you're relying on two trusted introducers: wherever the cryptoURL came from, and the CA. But for that price, you've purchased some resilience to EE key compromise. Trevor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Announcing httpsy://, a YURL scheme
On Wed, 16 Jul 2003 [EMAIL PROTECTED] wrote: A YURL aware search engine may find multiple independent references to a YURL, thus giving you parallel reporting channels, and increasing trust. But any single search engine is itself a single reference, regardless of how many times and contexts it uses to print the reference on the page. IOW, if you go to Mallory's search engine, then no matter how many references you find, they're all coming to you through the same channel and you have to trust Mallory. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
Mark S. Miller wrote: At 08:48 AM 7/16/2003 Wednesday, Ed Gerck wrote: IF Alice is trusted by Bob to introduce ONLY authentic parties, yes. And that is the problem. In order for the Carol that Alice introduces Bob to to be inauthentic, there must be some prior notion of *who* Alice was supposed to introduce Bob to. No. Alice may simply always introduce Bob to a fraudster, independently of *who* Bob wants to talk to. BTW, IMO this thread has suffered the constant, excessive use of sweeping statements and arguments. The way I see it, until the statement that Authentication of the target site MUST ONLY rely on information contained in the YURL is revisited, there is nothing much to discuss since there is already a single point of failure that is fatally built into the system. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
On Wednesday 16 July 2003 11:26, Perry E. Metzger wrote: It seems to me to be more a bad idea, fully realized. Perry, throughout this thread, you have made a number of factually incorrect statements about YURL. Never have you provided an argument to backup any of these statements. I know that you are under no obligation to make rational arguments about my work, but I fail to see how making irrational arguments is useful to anyone. Calling my work vomit seems even more spurious. I'll repeat: 1) The YURL makes key management and replacement effectively impossible. False. YURL makes key management *much* easier than it is under the PKI. See: http://www.waterken.com/dev/YURL/Why/#Certificate_lifecycle_control The HTTPSY specification states that: The client MUST construct a valid PKIX certificate path to a certificate that is signed using a public key whose hash matches the hash in the URL. This means that the public key hash contained in an httpsy:// YURL is the hash of the public key of the root certificate. Should a subject private key be compromized, the subject certificate can be revoked and a new public/private key pair created and certified. All existing YURLs remain valid. For example, the YURL for the Waterken Inc. site is: httpsy://[EMAIL PROTECTED]/ The private key corresponding to this public key hash has never existed on the Waterken Inc. server. Should someone hack into the server, I can set the site back up after reclaiming control of my server. Note that if you go to the Waterken Inc. site using the Waterken Browser, the public key you will use for the connection is only valid until Jul 26 16:50:33 2003 GMT. I only issued a certificate for one month. At the end of the month, I will issue a new certificate, closing the window of vulnerability for that particular private key. All YURLs will remain valid. I am actually practicing what I preach in the Why use YURLs? document. Read it. 2) It leads to situations in which you have no way to know what sort of trust relationship you have for the documents you're looking at. Garbage. As Mark Miller has so completely explained, there are only two possible sources of trust in *any* distributed system: the creator of the URL and additional sites that will vouch for the URL. You always know how you got the YURL, because someone has to send it to you and you have to receive it. At the very least, you know how you got the YURL. This establishes your initial trust relationship. You can then amplify the trust relationship by asking another trusted site to vouch for the YURL. In the Waterken Browser, this is implemented through the Pet Name system. When you receive the YURL, the browser looks it up in its database and tells you if the target site is one you have already been introduced to. This simple mechanism lets you combine introductions and manage trust relationships. These principles are explained in the YURL Definition, which you dismissed as peripherally interesting. See: http://www.waterken.com/dev/YURL/Definition/ 3) It is impossible for people to determine that a YURL actually is what it claims it is, given that most people can't actually remember one hash, let alone large numbers of them, etc. I can make no sense of this statement. First, a YURL doesn't claim to be anything. No URL does. The creator of a URL makes a claim. Other sites may also make claims. No one is being asked to remember any hashes. This has been pointed out to you multiple times, by multiple different posters. This is the whole point of the YURL Trust Management document. See: http://www.waterken.com/dev/YURL/Name/ I don't want this to be a confrontational discussion. I am saddened that it has become one. Please stop making baseless denigrations of my work. I am eager to receive constructive criticism, will receive it with grace and use it to build the best solution to our common problem. However, if you insist on calling my work vomit, then I will defend my work with equal zeal. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking for an N -out-of-M split algorithm
On Wed, 16 Jul 2003 [EMAIL PROTECTED] wrote: Hi, I remember reading (many years ago) a description on some web page somewhere of an algorithm by which an arbitrary file F could be split into M pieces, such that: (1) given any N pieces, F can be reconstructed precisely, and (2) given fewer than N pieces, it is impossible to determine even a single bit of information about F. Unfortunately, that was many years ago, and -- search as I might -- I haven't been able to find it on web now. Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. [Moderator's note: look for Shamir Sharing -- the trick is just turning the secret into a polynomial of degree N so that with enough points you determine the polynomial uniquely and with too few you can't determine it. I'm pretty sure that Schneier and all of the other standard references explain this trick. --Perry] Perry has it exactly right, although he was pretty brief and gave no examples. Let's say you want to be able to reconstruct a message given any two out of three splits of the message. What you do is plot the message as the y-intercept on a cartesian graph, and draw a line in some random direction. (where random != straight up) Now, the line you've drawn crosses the x=0 vertical line at the message, and it crosses the x=5000 line at some other point whose y coordinate is A, and it crosses the x=1 line at some other point whose Y coordinate is B, and it crosses the x=15000 line at yet some other point, whose Y coordinate is C. A, B, and C are your three secret splits. Unless someone has at least two of them, they have no information about the slope of the line and they can't project it back to the (x=0, y=M) point to get the message. If you want two out of four, or two out of six, or whatever else, it's the same thing; two points establish a line, so you can just pick more points along the line. If you want a 3-out-of-N secret split, you need to use a curve that requires three points to establish (such curves include functions of X^2). And so on... Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Looking for an N -out-of-M split algorithm
For large files, you might also want to take a look of the following paper Krawczyk, H. Secret sharing made short. In Advances in Cryptology -- Crypto '93. pages 136-146 See also HAC pages 539. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Looking for an N -out-of-M split algorithm Hi, I remember reading (many years ago) a description on some web page somewhere of an algorithm by which an arbitrary file F could be split into M pieces, such that: (1) given any N pieces, F can be reconstructed precisely, and (2) given fewer than N pieces, it is impossible to determine even a single bit of information about F. Unfortunately, that was many years ago, and -- search as I might -- I haven't been able to find it on web now. Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. Jill [Moderator's note: look for Shamir Sharing -- the trick is just turning the secret into a polynomial of degree N so that with enough points you determine the polynomial uniquely and with too few you can't determine it. I'm pretty sure that Schneier and all of the other standard references explain this trick. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking for an N -out-of-M split algorithm
Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. Just as Perry mentioned, look into Shamir Secret Sharing. There are also implementations of this, see for example http://www.astro.gla.ac.uk/users/norman/distrib/tontine.html (I'm not certain if I ever used that one in particular, so I don't know if it's good, but I'll let you do the research...). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
