I don't understand what makes this better than getting people to use existing encryption tools on messages that they insert under KSKs a-la the current system. Sure, people could request the data, but they wouldn't be able to decipher it so it wouldn't matter.
Ian. On Sat, Oct 06, 2001 at 11:59:15AM +1200, David McNab wrote: > I know this has popped up at different times, but I'd like to put it forward > for discussion again. > > There's a lot of value to be gained in a new keytype, a kind of 'reverse SSK'. > Perhaps call this keytype 'PAK' - Privately Accessible Key. > > In other words: > > 1) Generate a public/private keypair > 2) Trivial to convert the private key into a public key, but no way to > convert public to private except by brute force against extreme orders of > execution. > 3) Insert under the pubkey - easy. > 4) Requests using the pubkey fail - no data found > 5) Requests using the privkey succeed - plain data comes back > > I still know stuff-all about the node internals, but I could envisage > anything inserted under the pubkey being stored, heavily encrypted, under a > CHK. The PAK could be an SSK variant. PAK at pubkey physically contains a > redirect to this CHK. > > Upon request, the node converts PVK at privkey to PAK at pubkey to retrieve > the key, then the privkey is used to decrypt the data. > > Uses? > Secure email. > Secure payments. > And many more. > > Thoughts anyone? > > David > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011005/b490a49b/attachment.pgp>
