[cryptography] storage systems as one-way protocols

Marsh Ray marsh at extendedsubset.com
Tue Oct 5 19:11:24 EDT 2010


On 10/05/2010 02:04 PM, travis+ml-rbcryptography at subspacefield.org wrote:
> I don't know if anyone else noticed this but...
>
> Storage systems are basically a subclass of protocols; they're
> unidirectional (with no acknowledgements).  IOW, you're sending
> messages to yourself at some (future) point in space-time.
>
> The recipient cannot respond, so is necessarily unauthenticated.
>
> However, the converse is not true; the sender can apply a MAC
> to the data to assure the recipient it has not been altered.

Only if he can also transmit something else in such a way that the 
recipient can know that that was not altered. This something else could 
be a shared secret for a MAC or a public key. It could be much smaller, 
and there may be many fewer of them than messages, but you still have to 
be able to transmit something that the recipient trusts to verify the 
sender's identity. So it almost becomes as much a data compression 
scheme as much as anything else.

If its a shared secret, then it obviously has to stay secret. If you 
have a way to communicate such a shared secret, then you might as well 
just send a hash of the message secretly.

> Q: Do any storage cryptosystems do this?
>     How do they manage the metadata?
>
> Since it is a non-interactive protocol with no recipient
> authentication, anyone may be the recipient, and subject it to an
> attack, which is necessarily passive and offline.

Or they could modify the data and trick the recipient. Or make a third 
party believe incorrect things about the storing party. The attacker 
might cause data loss to go undetected for a period of time. Or they 
could cause the legitimate party to bear the costs and/or risks 
associated with storing the attacker's data. The attacker could make the 
storing party act as subliminal communications channel. Perhaps the 
attacker could cause the future recipient to leak information about the 
circumstances of the data's use.

> Q: What design criteria does this imply, compared to our standard
>     bi-directional protocols?

As mentioned, mutual authentication is out. No dynamic protocol 
negotiation. Forward secrecy doesn't apply. The sender will have no way 
to confirm that the message was successfully received.

> Q: What is the analog of a replay attack in the storage crypto
>     context?

An attacker could possibly make the recipient receive duplicate 
messages, or replace one message with another. He could obtain the 
shared secret as it was used to decrypt/verify one message and use it 
against others.

> Does it have something to do with not maintaining
>     positive control of your storage media at all times?

No, though that may have other benefits.

> In summary, it's very much like email encryption a la GnuPG.
>
> It may be further simplified, in that the recipient and sender are
> generally the same person.

That may be exactly what the recipient is trying to prove, "I am the one 
who sent this to myself". So we should be careful not to assume it as an 
inherent property.

> In LUKS, we may have several passphrases that unlock the storage key
> (which is merely what I call "key indirection", or a K-E-K).
>
> Q: What is the meaning of this, if we recast this as a protocol?

If it's just "any one of M keys" are sufficient to decrypt, you might 
consider that analogous to multicast, but otherwise it doesn't seem 
special. If it's an "N of M keys" scheme, then it could get more 
interesting.

> In some cases, the storage crypto may also encrypt the storage key
> to the pubkey for the enterprise, for key recovery reasons.
> Q: Are there other applications of PK in storage crypto?

Perhaps steganography and watermarking which use PK might fit your 
definition?

- Marsh



More information about the cryptography mailing list