Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ
[Request] Send Encrypted Token Emails
[Request] Send Encrypted Token Emails
The idea here is that when paying for a token, the TokenBot is able to use a PGP public key (supplied from either a keyserver or by the payment form) to encrypt token-bearing emails.
-
tweetnacltooo
Re: [Request] Send Encrypted Token Emails
Perhaps tweetnacl based crypted token emails as well ?
all that is required is the recipients minilock or tweetnacl public key --> minilock/ nacl based pub ids are nearly pseudonymous.
wallah and what do we have xD
all that is required is the recipients minilock or tweetnacl public key --> minilock/ nacl based pub ids are nearly pseudonymous.
wallah and what do we have xD
Re: [Request] Send Encrypted Token Emails
I would like to implement this, but the problem is that a lot of people create PGP keys tied to their email address just to test out PGP, without actually using it.
If tokenbot were to send an encrypted email to them, they might not still have the key/password needed to decrypt it.
Plus, there could be multiple keys for the same address, and we don't know which one is their active/valid one (maybe the one on the keyservers is different than the one they actually use).
If sending tokens in plaintext email is the issue, I think one solution would be to instead send token emails that contain a link to a webpage that displays their token. In order to avoid the whole account creation requirement, that link would show them their token only once. The added benefit to that is if the token link is invalid by the time the customer goes to the page, then their email was obviously intercepted.
The obvious problem is the same thing we have now where people accidentally delete the welcome email, or an overzealous spam filter prevents them from receiving the email.
Either way, tokens were designed to be nothing more than authorization tokens. If someone were to intercept the welcome email containing a customer's token, the most they could do with it is DoS that person by using up their token before the customer could. They can't decrypt traffic, or anything like that, with the token.
If tokenbot were to send an encrypted email to them, they might not still have the key/password needed to decrypt it.
Plus, there could be multiple keys for the same address, and we don't know which one is their active/valid one (maybe the one on the keyservers is different than the one they actually use).
If sending tokens in plaintext email is the issue, I think one solution would be to instead send token emails that contain a link to a webpage that displays their token. In order to avoid the whole account creation requirement, that link would show them their token only once. The added benefit to that is if the token link is invalid by the time the customer goes to the page, then their email was obviously intercepted.
The obvious problem is the same thing we have now where people accidentally delete the welcome email, or an overzealous spam filter prevents them from receiving the email.
Either way, tokens were designed to be nothing more than authorization tokens. If someone were to intercept the welcome email containing a customer's token, the most they could do with it is DoS that person by using up their token before the customer could. They can't decrypt traffic, or anything like that, with the token.