On 10/05/2010 02:04 PM, [email protected] 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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
