On Jan 4, 2010, at 1:17 AM, Robert J. Hansen wrote:
>> Morten Gulbrandsen wrote:
>>> Allen Schultz wrote:
>>>
>>>> Is there a way to force an expiration date when encrypting a message
>>>> for additional security.
>>
>> [...]
>>
>>>
>>> sure
>>>
>>> http://vanish.cs.washington.edu/
>
> There are, as near as I can tell, only three options: either (a) you
> trust the sender's clock, (b) you trust the recipient's clock, or (c)
> you trust a third-party clock.
>
> Once you know which clock the system is trusting, attack the clock.
> Subvert and/or impersonate it, rewind time back, and view the message again.
Did you read the Vanish paper? That's not how it works - there isn't some
piece of code that says "if (not_yet_expired) { show_data }". Rolling the
clock back has little effect. In Vanish, the key is broken into multiple key
shares (a la Shamir), and spread out over many machines in a large pool. At
expiration time (a regular occurrence on the node, and not specific to the
message), the key share is simply dropped. Eventually, enough shares are gone
that the key cannot be recovered. One could conjecture some master of the
universe attack against all of the nodes, but it's a very different trick to
subvert one machine than it is to subvert over a million of them (Vanish runs
over Vuze). Plus the attack would have to be mounted before the message
expires.
Of course, see http://z.cs.utexas.edu/users/osa/unvanish/ ;)
To be sure, Vanish doesn't solve the problem we're talking about here, but I
can't really hold that against it since that's not the problem it was designed
to solve.
David
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
