[Cryptography] Broadcast security identifier

[Phillip Hallam-Baker]

Keys are either public keys or private keys right? Well what if we had a
key that was a bit of both?

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.

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:

1) Locate the data
2) Decrypt the data
3) Verify the data

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.

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.

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).

SignatureKeyPair = {VerifyKey, SignKey}
Digest = Hash (ToBytes(VerifyKey), bits)

Next we need to generate an encryption key. So lets use HKDF to derive an
encryption key from Digest and a Salt value.

Salt = Random (128)
EncryptKey = KDF (Digest, Salt)

Now we envelope the data using our cryptographic keys:

Document = Envelope (SignEncrypt (Data, EncryptKey,SignKey), Salt,
Encrypt(VerifyKey, EncryptKey)

The locator for this document on the service is the Hash of the Digest
value:

Locator =  Hash (ToBytes(Digest , bits)

[I am eliding the Sign/Encrypt order debate here].

The QR code for the document is a URI which has embedded in it the
following information:

* Domain of the resolution service
* Locator

[Eliding the niceties of URI syntax etc.]


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.

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.

[It is necessary to encrypt VerifyKey or else this will allow someone to
reconstruct Digest!]


So besides comments on the proposal, has anyone seen a scheme like this
before?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200615/baeea419/attachment.htm>