RE: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote: [dropping tahoe-dev from Cc:] On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote: Zooko Wilcox-O'Hearn wrote: I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer ... Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? I'm sorry, I don't understand your sentence. Cleversafe isn't using threshold secret sharing -- it is using All-Or-Nothing-Transform (built out of AES-256) followed by Reed-Solomon erasure-coding. I would define that combination as a threshold secret sharing scheme. Noting of course what you said below in that it is a computationally-secure as opposed to Shamir's information theoretically secure scheme. The resulting combination is a computationally-secure (not information- theoretically-secure) secret-sharing scheme. The Cleversafe documentation doesn't use these terms and is not precise about this, but it seems to claim that their scheme has security that is somehow better than the mere computational security that encryption typically offers. Oh wait, now I understand your sentence. You in your sentence is the attacker. Yes, an information-theoretically-secure secret- sharing scheme does have that property. Cleversafe's scheme hasn't. Recalling what the original poster said: Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? Cleversafe's method does have this property, the difficulty in breaking the random transformation key does not decrease with the number of slices an attacker gets. Though the difficulty is not infinite, (as is the case with an information theoretically secure scheme) it does remain fixed until a threshold is reached. Jason - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
FW: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote: [dropping tahoe-dev from Cc:] On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote: Zooko Wilcox-O'Hearn wrote: I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer ... Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? I'm sorry, I don't understand your sentence. Cleversafe isn't using threshold secret sharing -- it is using All-Or-Nothing-Transform (built out of AES-256) followed by Reed-Solomon erasure-coding. I would define that combination as a threshold secret sharing scheme. Noting of course what you said below in that it is a computationally-secure as opposed to Shamir's information theoretically secure scheme. The resulting combination is a computationally-secure (not information- theoretically-secure) secret-sharing scheme. The Cleversafe documentation doesn't use these terms and is not precise about this, but it seems to claim that their scheme has security that is somehow better than the mere computational security that encryption typically offers. Oh wait, now I understand your sentence. You in your sentence is the attacker. Yes, an information-theoretically-secure secret- sharing scheme does have that property. Cleversafe's scheme hasn't. Recalling what the original poster said: Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? Cleversafe's method does have this property, the difficulty in breaking the random transformation key does not decrease with the number of slices an attacker gets. Though the difficulty is not infinite, (as is the case with an information theoretically secure scheme) it does remain fixed until a threshold is reached. Jason - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
On Aug 6, 2009, at 1:52 AM, Ben Laurie wrote: Zooko Wilcox-O'Hearn wrote: I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer, e.g. these claims from [3]: a malicious party cannot recreate data from a slice, or two, or three, no matter what the advances in processing power. ... Maybe encryption alone is 'good enough' in some cases now - but Dispersal is 'good always' and represents the future. Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? Until you reach the threshold, you do not have the information to attack. It becomes information theoretic secure. They are correct, if you lose a slice, or two, or three that's fine, but once you have the threshold number, then you have it all. This means that you must still defend the site from attackers, protect your media from loss, ensure your admins are trusted. As such, you have accomplished nothing to make the management of the data easier. Assume your threshold is 5. You lost 5 disks... Whose information was lost? Anyone? Do you know? What if the 5 drives were lost over 5 years, what then? CleverSafe can not provide any security guarantees unless these questions can be answered. Without answers, CleverSafe is neither Clever nor Safe. Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
[dropping tahoe-dev from Cc:] On Thursday,2009-08-06, at 2:52 , Ben Laurie wrote: Zooko Wilcox-O'Hearn wrote: I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer ... Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? I'm sorry, I don't understand your sentence. Cleversafe isn't using threshold secret sharing -- it is using All-Or-Nothing-Transform (built out of AES-256) followed by Reed-Solomon erasure-coding. The resulting combination is a computationally-secure (not information- theoretically-secure) secret-sharing scheme. The Cleversafe documentation doesn't use these terms and is not precise about this, but it seems to claim that their scheme has security that is somehow better than the mere computational security that encryption typically offers. Oh wait, now I understand your sentence. You in your sentence is the attacker. Yes, an information-theoretically-secure secret- sharing scheme does have that property. Cleversafe's scheme hasn't. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
[dropped tahoe-dev from Cc:] On Thursday,2009-08-06, at 17:08 , james hughes wrote: Until you reach the threshold, you do not have the information to attack. It becomes information theoretic secure. This is true for information-theoretically secure secret sharing, but not true for Cleversafe's technique of composing an All-Or-Nothing- Transform with Reed-Solomon erasure coding. CleverSafe can not provide any security guarantees unless these questions can be answered. Without answers, CleverSafe is neither Clever nor Safe. Hey, let's be nice. Cleversafe has implemented a storage system which integrates encryption in the attempt to make it safer. They GPL at least some of their work [*], and they publish their ideas and engage in discussion about them. These are all good things. My remaining disagreements with them are like this: 1. (The important one.) I don't think the access control policy of whoever can access at least K of the N volumes of data is the access control policy that I want. For one thing, it immediately leads to the questions that James Hughes was asking, about who is authorized to access what servers. For another thing, I would really like my access control policy to be fine-grained, flexible, and dynamic. So for example, I'd like to be able to give you access two three of my files but not all my other files, and I'd like you to then be able to give your friend access to two of those files but not the third. See Brian Warner's and Jason Resch's discussion of these issues: [1, 2]. 2. Cleversafe seems to think that their scheme gives better-than- computational security, i.e. that it guarantees security even if AES-256 is crackable. This is wrong, but it is an easy mistake to make! Both Ben Laurie and James Hughes have jumped to the conclusion (in this thread) that the Cleversafe K-out-of-N encoding has the same information-theoretic security that secret-sharing K-out-of-N encoding has. 3. Cleversafe should really tone down the Fear Uncertainty and Doubt about today's encryption being mincemeat for tomorrow's cryptanalysts. It might turn out to be true, but if so it will be due to cryptanalytic innovations more than due to Moore's Law. And it might not turn out like that -- perhaps AES-256 will remain safe for centuries. Also, Cleversafe's product is not more secure than any other product against this threat. It is hard to explain to non-cryptographers how much they can rely on the security of cryptographic schemes. It's very complicated, and most schemes deployed have failed due to flaws in the surrounding system, engineering errors or key management (i.e. access control) problems. Nobody knows what cryptanalytic techniques will be invented in the future. My opinion is that relying on well- engineered strong encryption to protect your data is at least as safe alternatives such as keeping the data on your home computer or on your corporate server. The Cleversafe FUD doesn't help people understand the issues better. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-July/002482.html [2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002514.html [*] Somebody stated on a mailing list somewhere that Cleversafe has applied for patents. Therefore, if you want to use their work under the terms of the GPL, you should also be aware that if their patents are granted then some of what you do may be subject to the patents. Of course, this is always true of any software (the techniques might be patented), but I thought it was worth mentioning since in this case the company authoring the software is also the company applying for patents. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
3. Cleversafe should really tone down the Fear Uncertainty and Doubt about today's encryption being mincemeat for tomorrow's cryptanalysts. It might turn out to be true, but if so it will be due to cryptanalytic innovations more than due to Moore's Law. And it might not turn out like that -- perhaps AES-256 will remain safe for centuries. Also, Cleversafe's product is not more secure than any other product against this threat. Since people do keep bringing up Moore's Law in an attempt to justify larger keys our systems stronger than cryptography, it's worth keeping in mind that we are approaching fairly deep physical limits. I wrote about this on this list quite a while back. If current physical theories are even approximately correct, there are limits to how many bit flips (which would encompass all possible binary operations) can occur in a fixed volume of space-time. You can turn this into a limit based solely on time through the finite speed of light: A computation that starts at some point and runs for n years can't involve a volume of space more than n light years in radius. (This is grossly optimistic - if you want the results to come back to the point where you entered the problem, the limit is n/2 light years, which has 1/8 the spacial volume). I made a very approximate guess at how many bit-flips you could get in a time-space volume of a 100 light- year sphere; the answer came out somewhere between 2^128 and 2^256, though much closer to the former. So physical limits prevent you from doing a brute force scan - in fact, you can't even enumerate all possible keys - in 100 years for key lengths somewhere not much more than 128 bits. It's rather remarkable that such fundamental limits on computation exist at all, but physics over the last 100 years - and especially over the last couple of decades - has increasingly shown us that the world is neither continuous nor infinite; it has solid finite limits on almost everything. Even more remarkable is that we've pretty much reached some of those limits. For any recently designed cryptosystem, brute force is simply out of the question, and will remains so forever (unless we are very much mistaken about physics). Moore's Law as a justification for using something more makes no sense. As you point out, the story for advances in cryptographic theory is much more complex and impossible to predict. That cryptographic advances would render the safer AES-256 at risk while AES-128 remains secure (for now) is something no one could have predicted, though in retrospect some of the concerns about the key scheduling may have been right. All the protocols and standards out there calling for AES-256 - it's obviously better than AES-128 because after all 256 is *twice as large* as 128! - were just a bunch of nonsense. And, perhaps, dangerous nonsense. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote: I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer, e.g. these claims from [3]: a malicious party cannot recreate data from a slice, or two, or three, no matter what the advances in processing power. ... Maybe encryption alone is 'good enough' in some cases now - but Dispersal is 'good always' and represents the future. Surely this is fundamental to threshold secret sharing - until you reach the threshold, you have not reduced the cost of an attack? -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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 majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
[cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com] Folks: It doesn't look like I'm going to get time to write a long post about this bundle of issues, comparing Cleversafe with Tahoe-LAFS (both use erasure coding and encryption, and the encryption and key-management part differs), and arguing against the ill-advised Fear, Uncertainty, and Doubt that the Cleversafe folks have posted. So, I'm going to try to throw out a few short pieces which hopefully each make sense. First, the most important issue in all of this is the one that my programming partner Brian Warner already thoroughly addressed in [1] (see also the reply by Jason Resch [2]). That is the issue of access control, which is intertwined with the issues of key management. The other issues are cryptographic details which are important to get right, but the access control and key management issues are the ones that directly impact every user and that make or break the security and usefulness of the system. Second, the Cleversafe documents seem to indicate that the security of their system does not rely on encryption, but it does. The data in Cleversafe is encrypted with AES-256 before being erasure-coded and each share stored on a different server (exactly the same as in Tahoe-LAFS). If AES-256 is crackable, then a storage server can learn information about the file (exactly as in Tahoe-LAFS). The difference is that Cleversafe also stores the decryption key on the storage servers, encoded in such a way that any K of the storage servers must cooperate to recover it. In contrast, Tahoe-LAFS manages the decryption key separately. This added step of including a secret-shared copy of the decryption key on the storage servers does not make the data less vulnerable to weaknesses in AES-256, as their documents claim. (If anything, it makes it more vulnerable, but probably it has no effect and it is just as vulnerable to weaknesses in AES-256 as Tahoe-LAFS is.) Third, I don't understand why Cleversafe documents claim that public key cryptosystems whose security is based on math are more likely to fall to future advances in cryptanalysis. I think most cryptographers have the opposite belief -- that encryption based on bit-twiddling such as block ciphers or stream ciphers is much more likely to fall to future cryptanalysis. Certainly the history of modern cryptography seems to fit with this -- of the original crop of public key cryptosystems founded on a math problem, some are still regarded as secure today (RSA, DH, McEliece), but there has been a long succession of symmetric crypto primitives based on bit twiddling which have then turned out to be insecure. (Including, ominously enough, AES-256, which was regarded as a gold standard until a few months ago.) Fourth, it seems like the same access control/key management model that Cleversafe currently offers could be achieved by encrypting the data with a random AES key and then using secret sharing to split the key and store on share of the key with each server. I *think* that this would have the same cryptographic properties as the current Cleversafe approach of using an All-Or-Nothing-Transform followed by erasure coding. Both would qualify as computation secret sharing schemes as opposed to information-theoretic secret sharing schemes. I would be curious if there are any significant differences between these two constructions. I don't think there is any basis to the claims that Cleversafe makes that their erasure-coding (Information Dispersal)-based system is fundamentally safer, e.g. these claims from [3]: a malicious party cannot recreate data from a slice, or two, or three, no matter what the advances in processing power. ... Maybe encryption alone is 'good enough' in some cases now - but Dispersal is 'good always' and represents the future. Fifth, as I've already mentioned, the emphasis on cryptography being defeated due to advances in processing power e.g. reference to Moore's Law is confused. Advances in processing power would not be sufficient to crack modern cryptosystems and in many cases would not be necessary either. Okay I think that's it. I hope these notes are not so terse as to be confusing or inflammatory. Regards, Zooko Wilcox-O'Hearn [1] http://allmydata.org/pipermail/tahoe-dev/2009-July/002482.html [2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002514.html [3] http://dev.cleversafe.org/weblog/?p=63 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
Folks: Over on the Tahoe-LAFS mailing list Brian Warner gave a typically thoughtful, thorough, and precise analysis of cleversafe access control as contrasted with Tahoe-LAFS access control. Brian attempted to cross-post it to this list, but it bounced since he is not a subscriber. http://allmydata.org/pipermail/tahoe-dev/2009-July/002482.html Jason Resch of cleversafe has also been participating in the discussion on that list. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
On Jul 24, 2009, at 9:33 PM, Zooko Wilcox-O'Hearn wrote: [cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com] Disclosure: Cleversafe is to some degree a competitor of my Tahoe- LAFS project. ... I am tempted to ignore this idea that they are pushing about encryption being overrated, because they are wrong and it is embarassing. and probably patent pending regardless of there being significant amounts of prior art for their work. One reference is “POTSHARDS: Secure Long-Term Storage Without Encryption” by Storer, Greenan, and Miller at http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf. Maybe they did include this in their application. I certainly do not know. They seem to have one patent http://tinyurl.com/njq8yo and 7 pending. http://tinyurl.com/ntpsj9 ... But I've decided not to ignore it, because people who publicly spread this kind of misinformation need to be publicly contradicted, lest they confuse others. ... The trick is cute, but I argue largely irrelevant. Follows is a response to this web page that can probably be broadened to be a criticism of any system that claims security and also claims that key management of some sort is not a necessary evil. http://dev.cleversafe.org/weblog/?p=111 # Response Part 2: Complexities of Key Management I agree with many of your points. I would like to make a few of my own. 1) If you are already paying the large penalty to Reed Solomon the encrypted data, the cost of your secret sharing scheme is a small additional cost to bear, agreed. Using the hash to “prove” you have all the pieces is cute and does turn Reed Solomon into an AONT. I will argue that if you were to do a Blakley key split of a random key, and append each portion to each portion of the encrypted file you would get similar performance results. I will give you that your scheme is simpler to describe. 2) In my opinion, key management is more about process than cryptography. The whole premise of Shamir and Blakley is that each share is independently managed. In your case, they are not. All of the pieces are managed by the same people, possibly in the same data center, etc. Because of this, some could argue that the encryption has little value, not because it is bad crypto, but because the shares are not independently controlled. I agree that if someone steals one piece, they have nothing. They will argue, that if someone can steal one piece, it is feasible to steal the rest. 3) Unless broken drives are degaussed, if they are discarded, they can be considered lost. Because of this, there will be drive loss all the time (3% per year according to several papers). As long as all N pieces are not on the same media, you can actually lose the media, no problem. This can be expanded to a loss of a server, raid controllers, NAS box, etc. without problem as long as there is only N-1 pieces, no problem. What if you lose N chunks (drives, systems, etc.) over time, are you sure you have not lost control of someone’s data? Have you tracked what was on each and every lost drive? What is your process when you do a technology refresh and retire a complete configuration? If media destruction is still necessary, will resulting operational process really any easier or safer than if the data were just split? 4) What do you do if you believe your system has been compromised by a hacker? Could they have read N pieces? Could they have erased the logs? 5) I also suggest that there is other prior art out there for this kind of storage system. I suggest the paper “POTSHARDS: Secure Long- Term Storage Without Encryption” by Storer, Greenan, and Miller at http://www.ssrc.ucsc.edu/Papers/storer-usenix07.pdf because it covers the same space, and has a good set of references to other systems. My final comment is that you raised the bar, yes. I will argue that you did not make the case that key management is not needed. Secrets are still needed to get past the residual problems described in these comments. Keys are small secrets that can be secured at lower cost that securing the entire bulk of the data. Your system requires the bulk of the data to to be protected, and thus in the long run, does not offer operational efficiency that simple bulk encryption with a traditional key management provides. Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
On Jul 26, 2009, at 12:11 AM, james hughes wrote: On Jul 24, 2009, at 9:33 PM, Zooko Wilcox-O'Hearn wrote: [cross-posted to tahoe-...@allmydata.org and cryptography@metzdowd.com ] Disclosure: Cleversafe is to some degree a competitor of my Tahoe- LAFS project. ... I am tempted to ignore this idea that they are pushing about encryption being overrated, because they are wrong and it is embarassing. The trick is cute, but I argue largely irrelevant. Follows is a response to this web page that can probably be broadened to be a criticism of any system that claims security and also claims that key management of some sort is not a necessary evil It seems to me there's a much simpler critique. The Cleversafe approach - which is not without its nice points - solves the key management problem in exactly the same way that some version of Windows solved the frequent General Protection Fault crashes problem (by eliminating the error message). The key management problem comes down to: I have encrypted data stored somewhere (where we assume attackers can access it, but not make use of it without the key). To make that data meaningful, I need to be able to locate the key appropriate to that data. What's a key? It's some private information. In Cleversafe's approach, I have data stored in pieces all over the place. To get at it, I need to know where the pieces of some data are. That information has to be secret, since anyone who has access to it can do the same computation and recover the data just as I can. Alternatively, I can rely not on the secrecy of that information, but on the discretion of those who hold the pieces. OK, but I could have done that with a simpler technique: Encrypt the data conventionally, then split the key among the trusted holders. That's a tiny, and more to the point, *fixed* overhead beyond the size of the data, which will always beat the cleverest Reed-Solomon or erasure coding. (It also has - if I use an appropriate mode - such nice features as random access to small parts of the data without the need to decrypt the whole thing first.) Granted, Cleversafe has other nice features. But other than changing the key management problem to the secret information needed to get at the data, which won't be used as a crypto key problem, I don't see how they've actually *solved* anything. Further: If I'm only encrypting stuff for myself, there's little reason to use multiple keys. The key management problem becomes interesting when there is different encrypted data with different access rights for different groups of users. It's beyond me how Cleversafe's approach makes this easier - or harder. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
cleversafe says: 3 Reasons Why Encryption is Overrated
[cross-posted to tahoe-...@allmydata.org and cryptogra...@metzdowd.com] Disclosure: Cleversafe is to some degree a competitor of my Tahoe- LAFS project. On the other hand, I tend to feel positive towards them because they open-source much of their work. Our Related Projects page has included a link to cleversafe for years now, I briefly collaborated with some of them on a paper about erasure coding last year, and I even spoke briefly with them about the idea of becoming an employee of their company this year. I am tempted to ignore this idea that they are pushing about encryption being overrated, because they are wrong and it is embarassing. But I've decided not to ignore it, because people who publicly spread this kind of misinformation need to be publicly contradicted, lest they confuse others. Cleversafe has posted a series of blog entries entitled 3 Reasons Why Encryption is Overrated. http://dev.cleversafe.org/weblog/?p=63 # 3 Reasons Why Encryption is Overrated http://dev.cleversafe.org/weblog/?p=95 # Response Part 1: Future Processing Power http://dev.cleversafe.org/weblog/?p=111 # Response Part 2: Complexities of Key Management http://dev.cleversafe.org/weblog/?p=178 # Response Part 3: Disclosure Laws It begins like this: When it comes to storage and security, discussions traditionally center on encryption. The reason encryption – or the use of a complex algorithm to encode information – is accepted as a best practice rests on the premise that while it’s possible to crack encrypted information, most malicious hackers don’t have access to the amount of computer processing power they would need to decrypt information. But not so fast. Let’s take a look at three reasons why encryption is overrated. Ugh. The first claim -- the today's encryption is vulnerable to tomorrow's processing power -- is a common goof, which is easy to make by conflating historical failures of cryptosystems due to having too small of a crypto value with failures due to weak algorithms. Examples of the former are DES, which failed because its 56-bit key was small enough to fall to brute force, and the bizarre 40-bit security policies of the U.S. Federal Government in the 90's. An example of the latter is SHA1, whose hash output size is *not* small enough to brute-force, but which is insecure because, as it turns out, the SHA1 algorithm allows the generation of colliding inputs much quicker than a brute force search would. Oh boy, I see that in the discussion following the article Future Processing Power, the author writes: I don’t think symmetric ciphers such as AES-256 are under any threat of being at risk to brute force attacks any time this century. What? Then why is he spreading this Fear, Uncertainty, and Doubt? Oh and then it gets *really* interesting: it turns out that cleversafe uses AES-256 in an All-or-Nothing Transform as part of their Information Dispersal algorithm. Okay, I would like to understand better the cryptographic effects of that (and in particular, whether this means that the cleversafe architecture is just as susceptible to AES-256 failing as an encryption scheme such as is used in the Tahoe-LAFS architecture). But, it is time for me to stop reading about cryptography and get ready to go to work. :-) Regards Zooko --- Tahoe, the Least-Authority Filesystem -- http://allmydata.org store your data: $10/month -- http://allmydata.com/?tracking=zsig I am available for work -- http://zooko.com/résumé.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
