 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / April 2004encryption key verification
Is there any way for a third party to verify that a document was encrypted with a particular key without revealing said key? That is, if I have a file F, and encrypt it with a key K. Is there any way for someone to verify that K was used to encrypt F with out compromising K? I don't mind using either a symetric or asymetric cipher, I just need K to be witheld until some very specific circumstances are met. Presumably this will require some intermediary steps to achieve, but I can't see them right now! Thanks in advance. -- Shane >Is there any way for a third party to verify that a document was >encrypted with a particular key without revealing said key? all public/private key schemes work that way e.g. RSA/PGP/DSA. There are two things you can do with public/private key systems: 1. encryption with the public key and decryption with the private key. Anyone can send you encrypted messages, but only you can read them. 2. digital signing with the private key and verification with the public key. Only you can sign messages, but anyone can verify that they came from you and were not tampered with. To play with this as a finished app, see http://mindprod.com/jgloss/pgp.html See http://mindprod.com/jgloss/digitalsignatures.html and follow links for a few days. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > all public/private key schemes work that way Apparently I did a poor job of explaining my problem. I'll start with the context. This question is essentially the same one I asked in c.l.j.programmer a while ago re: source code escrow. I have a potential new client who wants an escrow agreement. I have no problem with the nature of an escrow agreement, but there are no local agents, so I'm forced to work with a larger remote company and adhere to their rules. I'd also like to continue practicing frequent releases, so there will be a significant cost to keeping the code in escrow up to date. The only semi-viable answer I got on c.l.j.p. was to periodically cut cd's and deposit them in a safety deposit box. Given that this client is a few hundred km's away, I'm not sure if that would be an acceptable compromise. So I thought I pose the problem here behind a different facade. What I was thinking is that it would be possible to avoid having to update the file in escrow if it were just an encryption key which was stored at the third party location. The encrypted source file would be shipped with each build, but it needs to stay encrypted unless we go out of business. The scenario I'd like to pitch is something like the following: After a release build, all of the source is bundled into a source jar The jar is then digitally signed by us, so that someone can verify that it hasn't been tampered with (jarsigner -verify) The jar is then encrypted with a "not completely secret" key and then ftp'd to the client as part of the release. The encryption key would be duplicated and held in escrow. If we used the same key to encrypt each build, then there is no need to update the file held in escrow. The only tricky bit would be producing some kind of assurance / tracable evidence that we've used the escrowed key to encrypt the source jar. In a public/private key scenario, I'd have to encrypt the jar with my public key and hold the private in escrow. If that is done though, given that the private key is not available, how can someone verify that the appropriate public key was used to do the encryption? If you can't prove that a particular key was used to encrypt the jar, then the escrowed key is near worthless because one wouldn't find out until it was too late that a different key had been used. Does that make more sense? -- Shane > how can someone verify that the >appropriate public key was used to do the encryption? Even if you could, there is no guarantee that you included all the source, or that the source exactly matched the object, or that the source was not just a random collection of gibberish. I think the best you can do is send your source to the third trusted party, have them encrypt and sign it, and send it back to you for inclusion. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > Even if you could, there is no guarantee that you included all the > source, or that the source exactly matched the object, or that the > source was not just a random collection of gibberish. Yes, but this is also true of source escrow in general (although obviously you could test to see if it were gibberish). That's all I'm trying to achieve is something which is on par with escrow. > I think the best you can do is send your source to the third trusted > party, have them encrypt and sign it, and send it back to you for > inclusion. But this entails management of the returned material as well as fees for service. I think I'll go with the original version, perhaps I'll add a 'magic number' feature for slightly extra assurance (although that would be very easy to fake). There is as much assurance that I'm encrypting the real code with the right key as there is for me keeping the escrow service up to date with real code. Thanks for listening. -- Shane >There is as much assurance that I'm encrypting the real code with the >right key as there is for me keeping the escrow service up to date with >real code. A true escrow service would receive source, compile and run a validation suite, and perhaps run some simple hand script, and verify the results. They would validate that the sources were complete and that the validation suite. They could burn a CD and digitally sign in, attesting to this. The CD itself could be held in escrow by the escrow company, or copies could be made to be held by ordinary lawyer type escrow people. Along the some lines, it would be interesting if someone could invent a time capsule technology to seal documents for a given length of time. I guess it could be done by a trusted party who posted public encryption keys for the next 100 years. Each year they reveal the corresponding private key of the document. If the party could be trusted, ANYONE could create documents to be revealed only after their death. If the party went belly up, then the documents may never be opened. Those keys would need to be escrowed. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > The encryption key would be duplicated and held in escrow. If we used > the same key to encrypt each build, then there is no need to update the [quoted text clipped - 10 lines] > is near worthless because one wouldn't find out until it was too late > that a different key had been used. I don't know off hand how you prove the escrowed private key corresponds to the nominal public key without the cooperation of a third party that you and your customer both trust. If you both trust the third party escrower, the escrower can, for instance, form a digital signature of a customer-supplied nonce to prove that the third party does indeed have the correct private key. However, you can confirm that a given set of files was encrypted with keys that are encrypted with the nominal public key. Ideally, you'd want a zero-knowledge proof, but I don't have a ZK proof at hand. Divide the source into a lot of separate files. Encrypt each file with a different randomly selected symmetric key. I'm partial to AES, CTR and HMAC-SHA1, but the choice is up to you. Encrypt each file's symmetric keys (one for AES, one for HMAC) with the nominal public key. Give the customer the ciphertexts and the corresponding encrypted symmetric keys. The names of the ciphertext files need not correspond in any way to the names of the compiled .class files in the delivered .jar files. Allow the customer to select one file in each delivered set of files to be decrypted. For that file, use the private key to recover the file's symmetric keys and the padding bits that were used during the encryption of those symmetric keys. Allow the customer to confirm that the symmetric keys and padding bits do indeed form the correponding encrypted keys that were provided. Allow the customer to confirm that the ciphertext file does indeed have a valid MAC and decrypts to some kind of Java source using those symmetric keys. If the division of the source into files is on the basis of complete classes, then the customer could even, with the right compiler, confirm that the source compiles to the supplied .class file. This reveals some of the source. If there are a lot of deliveries to customers who insist on this verification every time, then nondisclosure agreements are appropriate. --Mike Amling Thank much, I'll have to digest this further. -- Shane Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.