network profile
| bio | website | staff.science.uva.nl/~ciancia/… |
|---|---|---|
| location | Amsterdam, Netherlands | |
| age | ||
| visits | member for | 9 months |
| seen | Feb 12 at 14:08 | |
| stats | profile views | 0 |
I am a travelling salesman, I spoke to God, I know the truth, but that's not because He told me.
|
Oct 19 |
comment |
Self-expiring symmetric keys, or: cryptography in absence of secure deletion My stronger constraint is that we do not trust the server, so we can not count on secure deletion. However, I am interested in solutions that involve some trust in a third party (that could become a peer to peer algorithm maybe) |
|
Sep 30 |
comment |
Self-expiring symmetric keys, or: cryptography in absence of secure deletion Well, I think it's "very standard" to encrypt something with a (randomly chosen) symmetric key and then encrypt the key with a private key. But yes, one needs to "bring around" Priv to access the data. Think there is one H for each piece of data C, so it would be unpractical to bring it with you when storing many data, while Priv is just one piece of information. |
|
Sep 28 |
comment |
Self-expiring symmetric keys, or: cryptography in absence of secure deletion @David Wachtfogel: I need that, since users should be able to get all of their data from the server, without storing anything else (think dropbox, or wuala, for the matter). |
|
Aug 27 |
comment |
Self-expiring symmetric keys, or: cryptography in absence of secure deletion Yes I imagine the random stream is available only for some time. Thinking about it, I can think of methods to "slow down" the stream in various ways, so for the moment let's assume the random stream generates a "large enough" number just "when I need it". Then I can encrypt the current key with the current number, and store the result on the server. Then I just need to refresh the key "when I need it". |
|
Aug 24 |
awarded | Student |
|
Aug 24 |
asked | Self-expiring symmetric keys, or: cryptography in absence of secure deletion |
