Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

An AES key is 128 bits, or 22 BASE64 characters. That's reasonable, and you can switch to BASE96 or Unicode.

This doesn't help if the server is malicious, but it does help if the server is honest but is later hacked/subpoenad/whatever. Generating a key entirely in RAM/encrypted swap is reasonable, and securely erasing RAM is easy (securely erasing individual files is nontrivial to say the least.)



I'm thinking that their unique ID (31 char) plus the key (AES 22) is a little long for a URL:

http://example.com/1234567890123456789012345678901/123456789...

I do like the idea though of keeping the secrets safe with a client-side (or non-stored) key. So long as it's known that it isn't about keeping the server honest, since you have to implicitly trust that they won't be storing the key.


TinyURL is currently giving out 8-character identifiers; I'm confident that those 31 characters can be trimmed a bit. ;-)


This is what I'm thinking. They could reasonably be unable to divulge your secret to a fourth party. The decryption could even be done client-side. They just generate a pair of (encrypted-secret, key). They store encrypted-secret and send you a pointer to it and the key, then destroy the key on their side.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: