4 ms·
> Consider adding forward-secrecy Considering. But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it
by kodablah 8y ago
> Consider adding forward-secrecy
Considering. But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point. Forward secrecy for the data at rest (i.e. in the DB) could have value but my current on-disk DB doesn't support this. But on the wire assumes MITM which should not be the case for user-to-onion. There is some defense in depth, but it's not something I'll target for MVP. There will be a built in data-expiration feature.
> and encrypting the payload
What does encrypting the payload help with when talking to an onion is already E2E encrypted? I do plan on encrypting at rest, but not in transit at least not at first. Could move to do TLS, but I'd be doubling Tor efforts because I'd probably just encrypt+sign w/ that same ed25519, so there'd be no real value.
- digianarchist 8y ago> "But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point." That's a problem with almost every messaging system. I wouldn't worry about that. > "What does encrypting the payload help with when talking to an onion is already E2E encrypted?" It would be a requirement of PFS, but I meant encrypt at rest - my mistake.