<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Keys are either public keys or private keys right? Well what if we had a key that was a bit of both?</div><div class="gmail_default"><br></div><div class="gmail_default">Specifically, what if we had a key that could be used to decrypt a document and to verify that the contents are correct without the ability to sign.</div><div class="gmail_default"><br></div><div class="gmail_default">I found a need for this type of key in my contact exchange protocol. Consider the case that we have a document that we are going to retrieve by means of a QR code. We have three separate requirements:</div><div class="gmail_default"><br></div><div class="gmail_default">1) Locate the data </div><div class="gmail_default">2) Decrypt the data</div><div class="gmail_default">3) Verify the data</div><div class="gmail_default"><br></div><div class="gmail_default">Authenticated encryption really doesn't cut it for the verification requirement as anyone who can read the data can fake the authentication tag. A MAC is only a MAC.</div><div class="gmail_default"><br></div><div class="gmail_default">We can communicate through two separate channels, through the QR code and through the document we retrieve. The QR channel being limited in space of course.</div><div class="gmail_default"><br></div><div class="gmail_default">Lets take the last of the requirements first, We want to verify the document. So lets generate a new signature key pair and sign the document. We put the public key parameters in the document itself and we embed the SHA-2 digest in the QR code, truncating to a reasonable number of bits (i.e. at least 128 but no more than 256).</div><div class="gmail_default"><br></div><div class="gmail_default">SignatureKeyPair = {VerifyKey, SignKey}</div><div class="gmail_default">Digest = Hash (ToBytes(VerifyKey), bits)</div><div class="gmail_default"><br></div><div class="gmail_default">Next we need to generate an encryption key. So lets use HKDF to derive an encryption key from Digest and a Salt value.</div><div class="gmail_default"><br></div><div class="gmail_default">Salt = Random (128)</div><div class="gmail_default">EncryptKey = KDF (Digest, Salt)</div><div class="gmail_default"><br></div><div class="gmail_default">Now we envelope the data using our cryptographic keys:</div><div class="gmail_default"><br></div><div class="gmail_default">Document = Envelope (SignEncrypt (Data, EncryptKey,SignKey), Salt, Encrypt(VerifyKey, EncryptKey)</div><div class="gmail_default"><br></div><div class="gmail_default">The locator for this document on the service is the Hash of the Digest value:</div><div class="gmail_default"><br></div><div class="gmail_default">Locator =  Hash (ToBytes(Digest , bits)</div><div class="gmail_default"><br></div><div class="gmail_default">[I am eliding the Sign/Encrypt order debate here].</div><div class="gmail_default"><br></div><div class="gmail_default">The QR code for the document is a URI which has embedded in it the following information:</div><div class="gmail_default"><br></div><div class="gmail_default">* Domain of the resolution service</div><div class="gmail_default">* Locator</div><div class="gmail_default"><br></div><div class="gmail_default">[Eliding the niceties of URI syntax etc.]</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">So now we have a URI which allows us to locate, decrypt and verify Data by working in reverse. The URI tells us where to find the document. We present only the hash of the decryption key IKM to the service to identify the document we wish to retrieve. The document gives us the necessary information to complete the derivation of EncryptKey.</div><div class="gmail_default"><br></div><div class="gmail_default">To verify the signature we take the values from the document envelope, decrypt the VerifyKey, check that the value Digest is correct and presents a sufficient number of bits to be trustworthy,  and validate the signature value.</div><div class="gmail_default"><br></div><div class="gmail_default">[It is necessary to encrypt VerifyKey or else this will allow someone to reconstruct Digest!]</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">So besides comments on the proposal, has anyone seen a scheme like this before?</div><div class="gmail_default"><br></div><div class="gmail_default">I am thinking it is probably still a public key scheme as we are still establishing two separate roles. Anyone with the QR code can decrypt but they can't sign. So the roles are divided into broadcaster and receiver. </div></div></div></div></div></div></div></div></div>