[Request] Send Encrypted Token Emails

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

[Request] Send Encrypted Token Emails

Post by parityboy » Sat Jun 10, 2017 5:18 pm

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.


Re: [Request] Send Encrypted Token Emails

Post by tweetnacltooo » Tue Jun 13, 2017 10:07 am

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

User avatar
Site Admin
Posts: 495
Joined: Thu Jan 01, 1970 5:00 am

Re: [Request] Send Encrypted Token Emails

Post by df » Mon Sep 18, 2017 3:55 pm

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.