commercial data recovery
[Note-- I am not subscribed to ietf-open-pgp at this time. My apologies if this submission from a non-subscriber is unwanted. I will be brief. --Zooko] Adam, I applaud your effort to steer discourse toward productive work re: GAK, CMR, CDR. I haven't thought about your idea enough to have a definite opinion, but at first blush it seems a promising strategy to design high-security and forward-secrecy for communication but recovery/sharing features for stored data. I wonder if it is too much early-days to start talking about advanced protocols e.g. secret-splitting in IETF-Open-PGP? Probably so. Better just punch out a standard with current tech... Hm. What about the idea of storing your data remotely (for cost-efficiency, safety, etc.) using encryption to maintain your privacy? In that case, the distinction between comms and storage keys is blurred. A company may choose to e.g. store all long-term data at Zooko's Backup Server, encrypted in such a way that some combination of corporate keys (controlled by individual employees and/or departments) is necessary to decrypt each package of data. This would open the door, as you fear, for a government to mandate that _its_ key be added to each set, with authority to open any package even without the cooperation of any corporate keys. I'm not sure how to weigh the relative risks and benefits. I (ever so humbly) think that Zooko's Backup Server would be a great value for businesses, and that part of that value would be the ability to make data unlockable by various keys, both for administrative/internal security purposes and for robustness against accidents and saboteurs. Zooko's Backup Server can be physically located in a country free of such intrusive organizations, but of course it is the intrusive organizations of the _client's_ country that become important with that kind of protocol... Regards, Zooko P.S. There is already a company whose name I have forgotten that offers hard-drive backups over TCP/IP. They use some encryption but I don't know how strong.
On Tue, 14 Oct 1997, Zooko Journeyman wrote:
Zooko's Backup Server can be physically located in a country free of such intrusive organizations, but of course it is the intrusive organizations of the _client's_ country that become important with that kind of protocol...
How about also having Alex' Backup Server, and using some shared-secret/whatever tech to ensure that you need to contents of _both_ servers to actually reconstruct the data. This would be a 'Distributed Encrypted Backup Sysyem'. This might make it very hard for anyone to access your data without your knowledge/cooperation. And if you use something like Onion Routers, it might even be quite impossible for some lawenforcement agency to actually find out which one of those encrypted files on the servers contains your backup. Alex --- I dabble in techno-house and sometimes, I do that badass hip-hop thang... But the F U N K gets me every time!
Zooko Journeyman <zooko@xs4all.nl> writes:
Adam, I applaud your effort to steer discourse toward productive work re: GAK, CMR, CDR. I haven't thought about your idea enough to have a definite opinion, but at first blush it seems a promising strategy to design high-security and forward-secrecy for communication but recovery/sharing features for stored data.
Thank you. I would encourage others to read the proposal, and provide criticisms of it.
I wonder if it is too much early-days to start talking about advanced protocols e.g. secret-splitting in IETF-Open-PGP? Probably so. Better just punch out a standard with current tech...
I agree entirely. The motivation for attempting to formalise the CDR design principles, and for exploring designs which are non-GAK compliant is based on these lines of reasoning, that we should: 1. Persuade PGP Inc that there are less GAK friendly ways of implementing data recovery 2. If that argument fails, and in the event that PGP were to try to influence the IETF OpenPGP forum to adopt any features relating to pgp5.5 GAK compliant functionality into the OpenPGP standard that we have an alternate proposal well enough thought through to compete with PGP's CMR proposal with sound technical arguments. 3. Of improving the state of the technology by working to include forward secrecy as much as possible into secure email messaging. This is a very effective method of giving the bird to the GAKkers, by purposefully destroying communications keys as soon as possible after the fact. This is consistent with the CDR design goal: make the GAKkers job as difficult as possible. Frustrating the GAKkers is a fun, morally satisfying activity.
Hm. What about the idea of storing your data remotely (for cost-efficiency, safety, etc.) using encryption to maintain your privacy? In that case, the distinction between comms and storage keys is blurred. A company may choose to e.g. store all long-term data at Zooko's Backup Server, encrypted in such a way that some combination of corporate keys (controlled by individual employees and/or departments) is necessary to decrypt each package of data. This would open the door, as you fear, for a government to mandate that _its_ key be added to each set, with authority to open any package even without the cooperation of any corporate keys.
The application you describe has very interesting implications for the CDR vs CMR debate. I think that one way that you could implement remote backup in a way which is sympathetic to CDR design principles like this: - The communications security aspect could be acheived via the normal design for securing communications derived from the CDR design principles. That is using short lived communications keys with no third party access to communications in transit without access to hard disks at either end. - The data would be super-encrypted to the companies backup recovery storage key(s). This technically violates the CDR design goal and principles of not allowing third party access to communicated data, super encryption doesn't negate this, it is just more structuring. However, super-encryption does minimise the damage by preserving CDR principle that recovery of data should require physical compromise of one or both end points, which I think is an important principle, and a useful property in this case. This lesson leads to the corollary to the CDR principles that: - if you can't keep to the principle of not transmitting data with third party recovery information attached, that: - super-encryption of the transmitted recoverable data can be used to at least preserve the requirement for one or both ends of the communication to be compromised to effect third party access. But still, the remaining way that this system could be perverted would be as you say for the GAKkers to demand to be one of the storage accessors for the encrypted disk backup, and for the GAKkers to then attempt to coerce the remote storage service provider to hand over the ciphertext, or for the government to set themselves up as a central provider of off site backup services. The GAKkers desire for automatic access to communicated storage data is frustrated to the maximal extent possible by those CDR design principles we have managed to retain. To achieve automated access the GAKkers must start replacing software, and we have prevented automatic snooping of our backup data whilst it is in communication, with software we have fielded. - CDR design principles do not prevent someone modifying software, but as we all know deployed systems are additional obstacles to overcome: they have to coerce some company in to implementing the new software with built in GAK, and they have to coerce everyone into replacing their existing software with this unpopular new software. Widely deployed systems can be large obstacles. The mess the US IRS in with their millions of lines of hard to modify source attest to this fact. The IRS scenario has some lessons for us, for possible additional CDR design principles: - keep the source code out of reach of GAKkers so that they can not coerce us so easily to modify it. Off shore backup might be useful; destroy the backup recovery key if GAK comes in. - make systems non-interoperable where this does not interfere with functionality - have mandatory GAK company contingency plans such as moving the company to Switzerland. That first suggestion costs so much in the loss of user access to source code to assure ourselves that there is no backdoor that we probably can't employ it. The other two look like sound principles to me.
Zooko's Backup Server can be physically located in a country free of such intrusive organizations, but of course it is the intrusive organizations of the _client's_ country that become important with that kind of protocol...
One comfort which can be drawn from the above design using super encryption inside a communications envelope protected with short lived non-escrowed communication keys, is that the fielded software could not be used as-is to prevent the practice of jurisdiction shopping. Another comfort is that companies can, even if forbidden from using offshore remote backup facilities, simply stop using remote backup facilities at all, unless the GAKkers really go overboard and demand that all citizen units will run this government remote backup software to upload diffs of their disks to government run backup services. I'm sure they would love to do that, and charge you for the "service" too. Also I expect there would be significant political hurdles for the GAKkers to overcome in mandating government run remote backup services for citizen units, or even for companies in our countries. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
While I think that a variety of robust and successful products will proably emerge that support various types of key recovery, I strongly agree with Tim on engineering grounds: Keep It Simple, Stupid. When it comes to deciding on the contents of a standard, let's keep in mind that we're working with a relatively new technology. We'll make more progress by standardizing proven concepts, and these integrated key recovery hacks don't have the operating history that vanilla PGP has. If anything, my experience with Guard keying suggests that the proposed mechansims aren't enough. The problem has more hair than our sheepdog. I don't think the protocol standard needs to take a political statement about key recovery mechanisms, but it *must* outline the protocol's traditional security objectives pretty much the way Tim outlined them. That sets the context for a robust protocol that has a successful history. Now I need to shut off my mailer and go pack my suitcase. Rick. smith@securecomputing.com Secure Computing Corporation "Internet Cryptography" now in bookstores http://www.visi.com/crypto/
I have an even simpler solution to the problem of how the OpenPGP committee should solve the key recovery/message recovery/corporate/GAK problem: Don't. Just decide and announce that neither plaintext nor key recovery will be part of the OpenPGP spec. This is a cleaner and simpler approach, and the functions of encryption are placed front and center. (Let some other task force deal with building some kind of "OpenGAK" or "OpenSnoopware" program!) That is, OpenPGP need only worry about providing a robust, secure, etc., open standard for end-to-end encyption (communication) and local encryption (storage). Don't try to solve the "disaster planning" problem ("Alice hit by a truck") by building snoopware/escrow into the core cryptosystem, and don't try to solve the snoopware ("What is Alice saying to Bob?") desires of companies either. For comparison, we certainly don't see the world's telecommunications bodies, committees, and companies working on a "conversation recovery" mode to make the job of enforcing the U.S. Digital Telephony and similar wiretapping desires. Dealing primarily with communication and file security is what PGP has historically focussed on, in all versions from 1.0 to 5.0 (not counting the anomaly of ViaCrypt). Sounds fine to me. The "mission" of PGP and other public key cryptosystems (until now) has been to secure communications and files, not to provide mechanisms for corporations to monitor communications. (Disaster planning, for "what if Alice gets hit by a truck?" scenarios, are of course handled by having Alice lock up her private keys in her safe, or perhaps her department manager's safe, whatever. This is a dangerous security flaw, if the key is released, but has the advantage that it's a fairly conventional recovery approach, and is not built into the cryptosystem itself. Trying to solve this problem, that of "backup keys" or "spare keys" floating around, is not easy in any case...OpenPGP would do well to just avoid the issue and let conventional disaster planning measures deal with the problem.) If corporations, agencies, governments, etc., want to have access to Alice's files, to Alice's communications to Bob, this is really a file managment and archiving strategy problem, not something OpenPGP has to concern itself with. Keep it Simple, Stupid. KISS. Often the simplest approach to dealing with complex specifications and conflicting desires is to just ignore them. Let Big Brother and Little Brother try to get snoopware deployed when OpenPGP is widely available. Whether PGP, Inc. will go along with this is unlikely, but this doesn't change the reasons for keeping OpenPGP true to the original aims of PGP. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
On Tue, 14 Oct 1997, Tim May wrote:
(Disaster planning, for "what if Alice gets hit by a truck?" scenarios, are of course handled by having Alice lock up her private keys in her safe, or perhaps her department manager's safe, whatever. This is a dangerous security flaw, if the key is released, but has the advantage that it's a fairly conventional recovery approach, and is not built into the cryptosystem itself.
Tim, The system above you are proposing is [C,G]AK, plain and simple. This is what some companies are doing already. And it is a Bad Thing. [Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.] -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred. "Tonga? Where the hell is Tonga? They have Cypherpunks there?"
Lucky Green <shamrock@cypherpunks.to> writes:
On Tue, 14 Oct 1997, Tim May wrote:
(Disaster planning, for "what if Alice gets hit by a truck?" scenarios, are of course handled by having Alice lock up her private keys in her safe, or perhaps her department manager's safe, whatever. This is a dangerous security flaw, if the key is released, but has the advantage that it's a fairly conventional recovery approach, and is not built into the cryptosystem itself.
Tim, The system above you are proposing is [C,G]AK, plain and simple. This is what some companies are doing already. And it is a Bad Thing.
It is GAK pervertable, but it is much more resistant to GAK perversion than PGP Inc's CMR system. I think Tim can reason pretty well without cribbing from the anti-GAK principles, but that he could present marginally more GAK-hostile systems by using the anti-GAK principles. (Or perhaps he would figure them out anyway but figures them to be too complex... my only real claim is that by working to these principles that it helps clarfiy what you are trying to defend against, and trying to avoid in your systems). The reason that you are right that what Tim suggests is GAK pervertable is that it partly violates one of the anti-GAK design principles I have been trying to hone. It violates the principle that recovery information should not be communicated (via sneaker net on a floppy to the company safe). It does however obey the corollary that: if you figure you must move recovery data, you should at least make it inconvenient, avoid electronic communicated recovery data, and generally require the recovery data to be as localised as possible. (Also the principles state that you should use forward secret comms keys, but I think that might be pushing it for sneaker net between machines and a laptop in the safe for ergonomics reasons :-) Here is how use of the anti-GAK design principles can help to provide a more GAK hostile system: It is better to use recovery rather than escrow. (Encryption of Alice's private key with a companies recovery key). This allows you then to store the recovery information more locally to the data, closest possible locality to data being another anti-GAK design principle. Now how is this harder than GAK? Heh well you need to use your imagination and try to make a system designed to fuck with the GAKkers minds at this point. Remember not only do you design the system to not communicate the key automatically, you try your best to prevent it being removed from the system. Here's a few ideas: You store the recovery info on the users disk only, but you do your damnest to obfuscate it. Encrypt it with keys hidden in the executable, obfuscate the code to hell and back, and don't provide source for that module. (Obfuscation tricks like interpreter of encrypted instruction streams ought to take a little bit of unwinding). You also hide the recovery data inside the keyrings, and obfuscate them to hell and back around the file system in slack space etc. This is to make it harder to copy to a floppy. So now the GAKkers can still get your recovery info, because they could theoretically unwind that problem. But it is sure a lot harder than requiring every one to email them a copy of the key they just put on a disk. The software doesn't give you any help obtaining your key in a mailable form, or in a form to stick on a floppy either. In fact it does it's damnest to prevent it. This is the kind of monkey-wrenching PGP should be investigating, rather than investing time in designing `elegant' GAK implementations. Combine with forward secrecy with as quick update time as you can manage without interfering with ergonomics issues, and the GAKkers have got to come back every 5 minutes, and grab a copy of your entire disk, or reverse engineer the obfuscation, to grab the next obfuscated key.
[Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.]
Wow, Lucky! I usually consider you to be spot on most such things, but I think you failed to hit the bulls-eye there; in fact I think you missed the dartboard entirely! I thought it was you who was pointing out earlier the fallacy induced by the key escrow meme (escrowing transient communicatoins keys with governments or companies to recover data stored on frigging disks!) (Actually you applied it just to goverments but the argument extends to companies perfectly). The only way that it's elegant is that it is an elegant fully ready to roll GAK implementation. (Notice Bruce Schneier's forward of a case of a GAKker already starting to crow about the demonstration of GAKware feasibility in PGP). There are plenty of less GAK compliant things you can do than what they are doing. The anti-GAK design principles help to clarify thought in designing a full spectrum from mildly GAK resistant through to rabidly GAK-hostile. I would hope that PGP (and you lot at C2Net) will crank the setting up to mad dog rabid anti GAK mode with nested obfuscated interpreters interpreting each other interpreting instruction sequences to recover keys. And busting your butts to make your systems ergonomic and slick to the extent that the competitors GAKware products look like dried up turds in comparison. Deployment being probably the most important anti-GAK principle of all! Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
On Wed, 15 Oct 1997, Adam Back wrote:
Lucky Green <shamrock@cypherpunks.to> writes:
[Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.]
Wow, Lucky! I usually consider you to be spot on most such things, but I think you failed to hit the bulls-eye there; in fact I think you missed the dartboard entirely!
So I am told. Which is surprising to me, since usually I am told that that I am too "paranoid" and "uncompromising".
I thought it was you who was pointing out earlier the fallacy induced by the key escrow meme (escrowing transient communicatoins keys with governments or companies to recover data stored on frigging disks!) (Actually you applied it just to goverments but the argument extends to companies perfectly).
I can't help but see a difference between enforcing to encrypt to a default key and storing the user's key outright. IMHO, the former entails less potential for abuse.
(Notice Bruce Schneier's forward of a case of a GAKker already starting to crow about the demonstration of GAKware feasibility in PGP).
There are plenty of less GAK compliant things you can do than what they are doing. The anti-GAK design principles help to clarify thought in designing a full spectrum from mildly GAK resistant through to rabidly GAK-hostile. I would hope that PGP (and you lot at C2Net) will crank the setting up to mad dog rabid anti GAK mode with nested obfuscated interpreters interpreting each other interpreting instruction sequences to recover keys. And busting your butts to make your systems ergonomic and slick to the extent that the competitors GAKware products look like dried up turds in comparison. Deployment being probably the most important anti-GAK principle of all!
Amen to the latter. I honestly don't see what PGP could have done better and still achieved deployment in companies that keep copies of all employees keys *today*. And yes, I think what PGP is doing is better than keeping copies of the keys of all employees. Anyway, I now have access to the entire PGP 5.5 system and will subject it to thorough analysis. Methinks many people arecurrently rendering opinions on a design they haven't even seen yet. Certainly, the part of PGP's SMTP agent that prevents you from screwing up by accidentaly sending sensitive email unencrypted stands a good chance of being installed at my site. [Can we all agree that this is a useful feature]? More than once, I failed to encrypt an email that I meant to encrypt. As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can therefore say that if my employer was to imlement GAK, I would quit the day I found out about it. It isn't going to happen. -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred. "Tonga? Where the hell is Tonga? They have Cypherpunks there?"
I thought it was you who was pointing out earlier the fallacy induced by the key escrow meme (escrowing transient communicatoins keys with governments or companies to recover data stored on frigging disks!) (Actually you applied it just to goverments but the argument extends to companies perfectly).
I can't help but see a difference between enforcing to encrypt to a default key and storing the user's key outright. IMHO, the former entails less potential for abuse.
Tim covered that pretty well. Inconvience is significant. If we can redesign the protocols or backup procedure so that the GAKker must modify software before GAK is even possible we have largely won. If we can accomplish subversion of the OpenPGP standard we may be on to a winner too... if PGP can't implement their beloved GAK functionality without being a non-conforming application. All it takes is for the standard not to accept the pgp5.5 CMR key extension. It really is too new and experimental to include says all. Let's include it as a may says Callas. No thanks says all, we don't want any of it; too new too experimental. If it comes to it, and I figured I could get away with it from a sales perspective I would toss out encrypted email data recovery altogether in preference to implementing GAK for the GAKkers. Implementing GAK for GAKkers has similar immorality to blowing away freedom fighters in foreign countries for sport -- it results in dead freedom fighters, and dead thought criminals (say boo to some governments, and they'll have your head on a platter within hours). The effect is not quite as direct, but it is surely the effect. Even for selfish reasons we don't want GAK for ourselves, and this eventuality is far from impossible in our respective countries.
There are plenty of less GAK compliant things you can do than what they are doing. The anti-GAK design principles help to clarify thought in designing a full spectrum from mildly GAK resistant through to rabidly GAK-hostile. I would hope that PGP (and you lot at C2Net) will crank the setting up to mad dog rabid anti GAK mode with nested obfuscated interpreters interpreting each other interpreting instruction sequences to recover keys. And busting your butts to make your systems ergonomic and slick to the extent that the competitors GAKware products look like dried up turds in comparison. Deployment being probably the most important anti-GAK principle of all!
Amen to the latter. I honestly don't see what PGP could have done better and still achieved deployment in companies that keep copies of all employees keys *today*.
Sure they could. Just simply switching from CMR to CDR: Store encryption key encrypted to a company recovery key on their disk. Or on a floppy in the safe even. No enforced second recipient necessary. Recovery of archived messages possible. Enforced second recipients are worse than straight forward escrow. This kind of thing is better for the reasons Tim listed in his defense of storing the keys in the safe on a floppy as opposed to second recipient. How about forward secrecy? You could make it even less GAK friendly if the keys only lasted for seconds. Then what are you going to do? Send a constant stream of keys to NSA HQ? What if the software tried it's hardest to not allow recovery or access to it's keys (it's hardly likely to given the desire for forward secrecy). So how can that be perverted for GAK? Does PGP investigate these? Hell no! They whinge: ergonomics, too complicated, not possible, you are having a group halucination, you don't understand software design. Yeah, that's right ain't it, we're group hallucinating, and Schneier -- bah they ain't listening to him -- he's just not understanding it right.
And yes, I think what PGP is doing is better than keeping copies of the keys of all employees. Anyway, I now have access to the entire PGP 5.5 system and will subject it to thorough analysis. Methinks many people arecurrently rendering opinions on a design they haven't even seen yet.
You could have a point there. Could you investigate and let us know what it does? important questions which I think are unclear: - does it provide message screening functionality (human reading mail prior to delivery in both directions?) - is pgp5.0 able to generate GAK compliant keys (CMR keys)? - how much control does the SNMP remote configuration provide in restricting user - can you have multiple CMR keys attached to a public key (like one for your company and one for the NSA?)
Certainly, the part of PGP's SMTP agent that prevents you from screwing up by accidentaly sending sensitive email unencrypted stands a good chance of being installed at my site. [Can we all agree that this is a useful feature]? More than once, I failed to encrypt an email that I meant to encrypt.
That part is a truly excellent feature. I do this myself manually, the mechanism I use that I read offline and use linux, so my mail is sitting in /usr/spool/mqueue waiting to go when the connectivity comes up. So I go check the files I care about prior to actually connecting. However that's not the controversial SMTP policy enforcer property. PGP Inc employees described that it rejects mail which is not CAK compliant.
As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can therefore say that if my employer was to imlement GAK, I would quit the day I found out about it. It isn't going to happen.
I wasn't suggesting C2 was GAK friendly. I was attempting to suggest that there are things you can do to be even more rabidly GAK-hostile than you already are. Think: monkey wrench GAKkers who might put this product to a work in a GAK setup. Make the product be awkward about the types of functionalities which they will want, make it drag it's feet, make it hide data which it doesn't want transmitted, make it cease to function when servers aren't local (eg. local LAN servers, make them refuse to work for IP#s not on the same sub domain). Be imaginative. PGP are at very best GAK neutral. It doesn't try hard to stop GAKkers deriving use from it. It tries somewhat to prevent users hacking around it's GAK features. It coincidentally (if you believe GAK neutral design philosophy) happens to be pretty useable to the GAKkers. It implements a method for a company which doesn't turn on the GAK feature to advertise that keys are read by company. Yeah nice, but big deal right? Contrast with trying to do all you can to ensure the product can not be used for GAK without a protocol modification, or without software recall, or non-backwards compatible widely fielded international standard rewrite. They do not appear to have tried any of these. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
I hate to insert a modicum of realism into an otherwise wonderful debate currently taking place on the Cypherpunks list in regard to the saints or sinners (depending on the angle that one is pissing from) at PGP, Inc.(arcerated, if PRZ hadn't folded his hand). However, my Bullshit Meter indicates that bullshit is currently 'en vogue' as the preferred 'opiate of the masses' and that the ultra-fine distinctions between GAK and CMR that are being hotly debated on the list are likely to be largely ignored by the huddled masses, yearning to be monitored. SURVEILLANCE==SECURITY Call it Double Speak or Spin Doctoring, it doesn't really matter. The citizen-units have bought into the 'America's Funniest Home Videos of Law Enforcement Agents Busting Dark Skinned Threats To Decent Americans On Prime-Time TV Thanks To Total Video Surveillance of the Citizenry' message being promulgated by the mainstream entertainment/news media. This is why nobody even blinked when legislation was recently passed which criminalized the possession of toilet plungers, except for those involved in meeting the legitmate needs of law enforcement to shove toilet plungers up the citizens' assholes. (Hell, I usually pay extra for that...) OK, so I just made that stuff up. Nonetheless, it *could* be true at some point in the near future, if DoubleSpeak, NewSpeak, SpinSpeak and I'mTooTiredToFightItAnymoreSpeak become the unchallenged rule of the day (which is not far from becoming a total reality). However, the point which I am not terribly concerned about making is this: The great sin of ViaCrypt/PGP is that they are failing to maintain standards of integrity that are far above that of the large mass of humanity that they are counting on to comprise the bulk of their customer base. What is the quote...??? "Nobody ever went broke underestimating the intelligence of the public." (?) I would very much prefer that ViaCrypt separate their 'Corporate Message Recovery' software from the PGP name/reputation-capital, but I would rather the situation remain as it is than to see PGP/ViaCrypt go under and leave the encryption software field to those with *no* history of 'doing the right thing.' I sincerely hope that the CMR software is the result of those designing it getting caught up in the erronius security concepts being promulgated by those with a fascist axe to grind, and that it is not the result of people of integrity 'consciously' averting their gaze from reality in order to increase their bottom line. If the current form of PGP/CMR is the result of normal diversion of the optimum design, due to the time/monetary pressures of everyday business, then the flaws in the product can be rectified in the future. If this is not the case, then it will be incumbent upon those who are aware of the dangers the technology presents, in its current form, to develop viable methods of circumventing the technology's flaws and/or weaknesses. To tell the truth, my main concern with the direction that PGP/CMR has taken is that there are not many role models left in life, and it would be a shame to lose yet another one due to lack of the character and perserverance that is needed to go against the grain of everyday business reality. The posts to the Cypherpunks list surrounding the issues involved in the current release of corporate PGP have been very enlightening to those of us who count on those such as Peter, Adam, William and others to 'shake it down' from a technical perspective. However, the pros and cons being debated on the list will have little meaning in the long run if those of us who are capable of understanding the issues involved do not take the time, and make the effort, to fully understand the implications involved, and to use whatever influence we have in society and the computer industry to rail against the dangers and work toward optimum solutions to the weaknesses and shortcomings in the technology which can threaten privacy, liberty and freedom. The fact of the matter is, although a company does indeed have a right to exercise control and supervision over their business affairs, they have no right to exercise the same amount of control and supervision over an employee's phone call or email to his or her spouse, or family members, or their communications with the cable company over when they can be present at home to have their cable TV hooked up. If a company has set up a system whereby an employee needs to ask permission to make an unmonitored phone call, or send a personally encrypted email during the course of the business day, then the company and the employee have become adversaries. Governments and Corporations become fascist dictators 'by default.' When they remain conscientious, humanitarian institutions over a long period of time, it is the result of the efforts of those within the governments and corporations to 'make' it so. If man does not rule the machine, then the machine will rule the man. [Women rule *both* (;->)------(<-;)] There is a far cry of diffenence between: 1) "Boss, can I have permission to talk privately, without supervisory monitoring, to my child's doctor, since he/she is sick and the doctor needs to speak frankly and privately to me?" and 2) "Boss, I needed to speak privately to my child's doctor, so I bypassed the monitoring mechanisms and informed my supervisor as to my reasons for doing so." and 3) "Boss, I damn glad I work in one of the few remaining companies where I am trusted to act in the best interests of both myself and the company, and not be spied on over every minor detail out of a sense of mistrust." I realize that we live in a world where the company president (of Borland?) can steal company secrets and take them with him/her to his/her new place of employement. And janitors can go through the garbage to gain access to company secrets that they can sell to the competition. However, I truly believe that TOTAL SECURITY is an impossible goal, and that internal company security should be geared toward making it necessary for outside forces to attack the system in order for the corporate information system to be compromised. The situation within a company is much the same as the situation within a country. Even the most fascist and draconian of rules and regulations will not prevent the anti-fascists and anti- draconians from playing the secrecy/security game better than one's own players. (Or prevent the janitor from inadvertently leaving valuable corporate information lying on the top of the garbage pile.) Corporate Security is not a far cry different from National Security or Private Security. All involve an elliptical curve beyond which 'security' becomes our oppressor, rather than our savior. I have listened closely to both sides of the debate over corporate interests versus government shenanigans, and do not disagree too strongly with either side of the debate. I believe what may be understated is the reality that any government, any philosophy or psychology, any devised system of democracy or security, is dependent upon the knowledge, wisdom and integrity of those who are involved in upholding the concepts underlying it. It matters little whether the Supreme Court is 'stacked' with liberals or conservatives, it is still 'stacked.' It matters little whether we are 'pretending' to listen to the arguments of our 'liberal' or 'conservative' foes, we are still 'pretending' to be men and women of reason. The great danger that exists is that men and women of high intellect and reason will make the mistake of assuming that their fellow primates are working off of the same game sheet as they are. If the same party takes all of the steps backward, as the other party keeps stepping forward, then the word 'compromise' is being misused. Buy a clue... I have no more desire to live in a world full of Dimitri Vulis's than I do to live in a world full of Tim C. Mays. I want to live in a world full of CypherPissers who shoot themselves in the foot as often as they shoot each other in the head, so that the Universe maintains its natural balance. Ignorant incompetence is a far less troubling manifestation than is that of conscious evil. Yet we live in a world that 'condemns' the former and 'compromises' with the latter. What I find troubling is the fact that 'evil' seems to have a game plan, while 'good' seems to be locked in an endless argument over how to proceed so that every aspect of life remains unequivocably 'equal,' no matter whether nature itself cries out against it. In effect, 'evil' is in agreement, and advances, while 'good' is locked in battle with itself, arguing over how many angels can stand on the head of a pin. The longer we refrain from speaking out against the evils of Waco, the more we will be faced with OKC bombings. If all of us had protested loud and long over the Waco injustice, then there would have been no need for the universe to balance it out with OKC. The turbulence and/or violence of our future is dependant upon where we draw the line, as individuals and as a society, where we say, "This far, and no further." The end result of the government's promotion of GAK, or PGP's implementaion of CMR, will not be dependent upon the aims and goals of those promoting and developing the concepts and the underlying methodologies behind them, but upon the willingness or unwillingness of you and I to 'go gently into the night' when we are faced with an opponent who steps across the line we have drawn in the sand to represent our own beliefs and level of personal integrity. The more of us who are willing to compromise by 'moving' that line, the more that Doom closes quickly around us, and we are hung on the cross, with Nine Inch Nails. Bianca ~~~~~~
-- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred. "Tonga? Where the hell is Tonga? They have Cypherpunks there?"
"Alice? Alice? Who the fuck is Alice? Is she a Cypherpunk?"
I'll try a different way of making my points... At 9:12 PM -0700 10/14/97, Lucky Green wrote:
I can't help but see a difference between enforcing to encrypt to a default key and storing the user's key outright. IMHO, the former entails less potential for abuse.
All other things being equal, maybe the former is slightly less intrusive than the latter. But maybe not even this, as the two give the same results. After all, what's the real difference between "all mail, incoming and outgoing, must also be encrypted to a CMR key" and "you must deposit a copy of your key with us"? And things are most definitely not equal, in the "all other things being equal" sense. To wit, with the "storing a user's key outright" approach, if thousands of companies and whatnot are doing this, there will be a mishmash, a welter, of confusing, conflicting, byzantine arrangements. Some employees will store their mandated spare keys in the department safe, some will put them in "open upon my death" envelopes, some will "forget" to update the files with their latest keys, and so on. With this chaotic and anarchic approach, of "let a thousand solutions bloom," Big Brother will have the devil of a time forcing GAK/GMR (_Government_ Message Recovery_). It's essentially the chaotic, anarchic, non-system being used today. (And I've seen little evidence corporations are collapsing; as noted in several messages, very few pieces of e-mail are terribly critical, and even fewer can't be recovered from local files...the market for CMR is for law enforcement and e-mail snoopers.) By contrast, a CMR system BUILT INTO PGP (!) will potentially become widespread, especially if support of the non-CMR-compliant version languishes. Or, God forbid, CMR is mandated (perhaps by "Standard Accounting Practices" sorts of pseudo-mandates). I'll take the chaotic and anarchic solution. And no matter how "elegant" PGP Inc.'s solution is--which I reserve judgement on, not having studied in as much detail as, say, Adam Back has--no matter how "elegant," it is still building a dangerous tool for surveillance into a widely-deployed product. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
Tim May <tcmay@got.net> writes:
I'll try a different way of making my points...
At 9:12 PM -0700 10/14/97, Lucky Green wrote:
I can't help but see a difference between enforcing to encrypt to a default key and storing the user's key outright. IMHO, the former entails less potential for abuse.
All other things being equal, maybe the former is slightly less intrusive than the latter. But maybe not even this, as the two give the same results. After all, what's the real difference between "all mail, incoming and outgoing, must also be encrypted to a CMR key" and "you must deposit a copy of your key with us"?
CMR keys are the root of all evil in pgp5.5. Without them almost any permutation of recovery care to construct would be less useful to the GAKkers, for all the organisational, and inconvenience reasons Tim describes. Governments have problems handling complexity. So make their job complex. If you were one of the people writing the IRS tax software back in the 60s, and you were in deep cover, a proto-cypherpunk, and were bright enough to see the future possibilites you would have done all you could to fuck up the IRS system. You would have obfuscated the code. You would have put logic bombs in it. You would have destroyed the source code surreptisiously. (Destroying source code has analogies to destroying keys at earliest opportunity, you are destroying something which your enemy needs). Any bets as to if any of this actually happened on purpose? I reckon so. So, do you all reckon we can make task of fielding GAK impossibly complex for such a big disorganised government? Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
At 4:48 PM -0700 10/14/97, Lucky Green wrote:
On Tue, 14 Oct 1997, Tim May wrote:
(Disaster planning, for "what if Alice gets hit by a truck?" scenarios, are of course handled by having Alice lock up her private keys in her safe, or perhaps her department manager's safe, whatever. This is a dangerous security flaw, if the key is released, but has the advantage that it's a fairly conventional recovery approach, and is not built into the cryptosystem itself.
Tim, The system above you are proposing is [C,G]AK, plain and simple. This is what some companies are doing already. And it is a Bad Thing.
Maybe it's a bad thing, maybe it's not. But at least it isn't built into the cryptosystem itself. (As noted, building it into the infrastructure is very dangerous.) (Personally, I keep a diskette containing a copy of my secret keys, and a "hint message to myself" reminding me of my passphrases, in a Safe Place (tm). If I had a lawyer, I might seal an envelope with such a diskette in it and ask him to hold it for me. And if I had a company, I might insist that employees using crypto as part of their everyday jobs make similar arrangements. Such has it always been with crypto, right?) Building the options into a cryptosystem make it entirely too easy to government to mandate GMR (Government Message Recovery).
[Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.]
No, PGP Inc. did not "have" to do anything. Any more than Schlage Locks has to develop a strategy for dealing with customers who leave spare keys under rocks, or with their neighbors, etc. Or that telephone switch companies have to develop a strategy for delivering phone surveillance products, even though some companies make it a practice to monitor or snoop on employee calls. You are a minority for the reasons Phil Zimmermann, Bruce Schneier, Peter Trei, and many other people have expressed: what the New PGP Inc. is doing is not in keeping with the personal privacy goals formerly espoused. And as Schneier noted yesterday, the support by PGP for "message recovery" is already being used by Congress as an arguing point that it is indeed practical and should be made mandatory. Snooware is snoopware. PGP should stay out of this can of worms. (I can't resist another possible parallel. It's a fact that some companies use video surveillance, and microphones, to monitor employees. For drug use, for theft of produced goods, etc. And this is usually legal, except in some circumstances (restrooms, break rooms, and so forth). So, suppose a CRT maker decided to "meet this need" for employee surveillance by building a small video camera into each of its "Monitors for Monitors" line of CRTs? Would you still say that this is _elegant_? Me, I'd harshly criticize the company making the monitors, not because it is illegal, but because building in a surveillance state infrastructure is very dangerous and even immoral.) --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
On Tue, 14 Oct 1997, Tim May wrote:
And as Schneier noted yesterday, the support by PGP for "message recovery" is already being used by Congress as an arguing point that it is indeed practical and should be made mandatory.
I missed that one. [Just spent four days at an intensive training improving my fail-safe skills]. -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred. "Tonga? Where the hell is Tonga? They have Cypherpunks there?"
Lucky Green <shamrock@cypherpunks.to> writes:
On Tue, 14 Oct 1997, Tim May wrote:
And as Schneier noted yesterday, the support by PGP for "message recovery" is already being used by Congress as an arguing point that it is indeed practical and should be made mandatory.
I missed that one.
They're right too that it is possible (though less secure). That's the purpose of the anti-GAK design principles, see [1] below. They codify a design process for how to fuck with: - protocol designs - standardisation processes - implementations to make them as GAK-hostile as possible. There is a scale from: pro-GAK: (USG, NSA, TIS, IBM) (give me video cams in all bedrooms) GAK neutral: (implementer who just implements ignoring political argument of whether or not GAK will come in believing it irrelevant) GAK-hostile: (implementer who is rabidly anti-GAK, and wants to stop the GAKkers at all costs; he wants to manipulate protocol standards settings processes to ensure what results is not just `not GAK' if implemented in one way, he wants to make sure that it is impossible to be both conformant to the standard and implement GAK, then he wants to implement to that anti-GAK-infiltrated standard and deploy as many of his units as possible all implemented as GAK-hostily as possible, with user ergonomics, functionality and presentation m$ would die for). I really truthfully am completely puzzled as to PGP. They make nice pro-privacy rants (eg Jon Callas), but yet they are implementing a GAK compliant system, and one which can also be used to itself fullfill full GAK requirements without any software modifications. It could literally be plugged in tommorrow. This is inconsistent. Then myself, Tim May, Peter Trei, Bruce Schneier, Peter Gutmann, and most of the rest of cpunks, and OpenPGP, go over and over what is wrong with it, how to do it in non-GAK pervertable ways, or not to do it at all. And pgp _doesn't get it_. I am non-plussed. Are we suffering group hallucination here and are we all totally confused? Or is something very strange going on insde pgp's building? What _is_ going on in there? Are they arguing? Are they blissfully ignorant that the GAKkers are applauding their efforts? Has the corporate mind set take over? Have they done a deal with the Feds? Have they got $ signs in front of their eyes and forgotten that they were once pro-privacy (those that ever were; I guess some of the are just various suits). I thought they were supposed to be on our side?
[Just spent four days at an intensive training improving my fail-safe skills].
`fail-safe'? As in blowing holes in cardboard cutouts with `fed' written across them at 50 yds with a large bore weapon full of hollow-points? Sounds phun :-) Another form of backup plan is to get the fuck out when GAK hits. Go move to switzerland, or anguilla or somewhere from which to continue your after the fact monkey wrenching. (Is switzerland any good? Only place other than UK I have citizenship -- actually not true have US two through wife dual nationality, but I'm not sure about US right now -- may get to GAK before UK lot do). (pls excuse if `fail-safe' means something entirely unrelated, I'm not familiar with the euphamism/technical term). Adam [1] ====================================================================== Date: Tue, 14 Oct 1997 10:37:21 +0100 From: Adam Back <aba@dcs.ex.ac.uk> To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net Cc: cryptography@c2.net Subject: proposal: commercial data recovery If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) system down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo@imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE-----
[Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.]
Actually, I think you'll find that most people on the list think PGP's method is better than a lot of other things. It is elegant. But, as Adam has been pointing out, there are better methods. :-) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNEQquDc3ytqHnNyNAQGHvwP+JYTOg5IhciQ9Evm7W9jrmwxx8DNb7oww n2KTeveEIj6K2lHksLZHvbT7//zfTXcol7IiPoHSnoHL6Z6Q6af6+7O5I9VwPNWo +jGOLpbCFtdpvniaeugLCaji5/oQTx9HMu05n5Gj+iERShesCiXJaSU7CBq6qRi5 4iFmn7nxNkU= =Ej6P -----END PGP SIGNATURE----- ----------------------------------------------------------------------- Ryan Anderson - <Pug Majere> "Who knows, even the horse might sing" Wayne State University - CULMA "May you live in interesting times.." randerso@ece.eng.wayne.edu PGP Fingerprint - 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 -----------------------------------------------------------------------
At 12:14 PM -0700 10/15/97, Rick Smith wrote:
While I think that a variety of robust and successful products will proably emerge that support various types of key recovery, I strongly agree with Tim on engineering grounds: Keep It Simple, Stupid.
When it comes to deciding on the contents of a standard, let's keep in mind that we're working with a relatively new technology. We'll make more progress by standardizing proven concepts, and these integrated key recovery hacks don't have the operating history that vanilla PGP has. If anything, my experience with Guard keying suggests that the proposed mechansims aren't enough. The problem has more hair than our sheepdog.
I don't think the protocol standard needs to take a political statement about key recovery mechanisms, but it *must* outline the protocol's traditional security objectives pretty much the way Tim outlined them. That sets the context for a robust protocol that has a successful history.
Thanks for the comments, and the support is nice, too. As Rick notes, the whole "foobar recovery" (where foobar may be plaintext messages or keys) technology is untested, besides being dangerous in various ways. It represents an escalation of complexity, both for the users and the developers. (My message is being directed at the OpenPGP folks trying to figure out what features to support, not to PGP, Inc., which can make its own decisions about how to spend its engineering and marketing resources...though I hope they are taking the reactions of many of us to heart.) At this stage, where governments of the world are planning to make foobar recovery mandatory (either GAK or GAP), it's a bad time to launch an untested and potentially dangerous technology. As others have noted, Congress is already using PGP's support of message recovery as evidence that industry can rise to the challenge of providing message recovery for law enforcement. OpenPGP needs to stick to basics. And PGP, Inc. needs to get back to basics. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
-----BEGIN PGP SIGNED MESSAGE----- G'day all. Zooko Journeyman wrote:
I wonder if it is too much early-days to start talking about advanced protocols e.g. secret-splitting in IETF-Open-PGP?
One list member has encouraged me to write an internet-draft for a key quorum system, so I am. The trouble is that my proposed implementation needs some info that isn't in the current IETF draft (the format of the "string to key" object). Is it actually documented anywhere that we can access? Cheers, Andrew Bromage -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNEQHMBF7J5ORR6ohAQEtJQP/XlunlxxrKDwh0zlTBiWeURSvUbo3Lvup vp+Ex9gyraWuX+eaIoioQw+iQ7uLlWxeCRPVlVrpsnYG4YJF7vO1QKVxHuTZEbXj wUZyS8WXv+3TRjakCfKf2nNP6lDgYs2W67eZhmYzuwC/2uNn078DbAWg8TLcy1ji GvKEy0n4pLI= =4Ypn -----END PGP SIGNATURE-----
participants (10)
-
Adam Back -
alexlh＠xs4all.nl -
Andrew Bromage -
Bianca -
Lucky Green -
lutz＠taranis.iks-jena.de -
Rick Smith -
Ryan Anderson -
Tim May -
Zooko Journeyman