Concerns re: distribution of tokens
Concerns re: distribution of tokens
OK so first of all, the tokens are distributed via plaintext email. No message-layer crypto.
So since I use Gmail, Google can intercept and decrypt my cryptostorm traffic.could decrypt my cryptostorm traffic if they managed to intercept it. No good!
Second, the emails aren't DKIM signed so they could have been intercepted and modified without my knowledge.
Knowing this, I propose distributing tokens via the https://cryptostorm.ch website after payment, and by email iff the recipient has a GPG pubkey publicly available. If so, the email should be signed and encrypted to the recipient (as well as shown via the website) and if not, the token should only be shown via the website (with a message stating it won't be emailed).
Just my two cents.
So since I use Gmail, Google can intercept and decrypt my cryptostorm traffic.could decrypt my cryptostorm traffic if they managed to intercept it. No good!
Second, the emails aren't DKIM signed so they could have been intercepted and modified without my knowledge.
Knowing this, I propose distributing tokens via the https://cryptostorm.ch website after payment, and by email iff the recipient has a GPG pubkey publicly available. If so, the email should be signed and encrypted to the recipient (as well as shown via the website) and if not, the token should only be shown via the website (with a message stating it won't be emailed).
Just my two cents.
Re: Concerns re: distribution of tokens
Hmm.. any ideas to this? Since encrypted emails when at rest or after deletion are still outside our direct control.
Re: Concerns re: distribution of tokens
What do you mean?nonmalleable wrote:Hmm.. any ideas to this? [...]
Re: Concerns re: distribution of tokens
@OP
I think you have things a little mixed up. The token simply serves as an access key to authenticate you with the VPN service. It has nothing to do with the encryption mechanism itself, that's handled completely separately.
In the same way - for example - your username and password for logging into a website have nothing to do with the SSL encryption between the browser and the web server. They are completely different things.
At worst, someone reading your email will get a free token that you've just paid for, But, that's literally the worst that could happen.
Hope this helps.
I think you have things a little mixed up. The token simply serves as an access key to authenticate you with the VPN service. It has nothing to do with the encryption mechanism itself, that's handled completely separately.
In the same way - for example - your username and password for logging into a website have nothing to do with the SSL encryption between the browser and the web server. They are completely different things.
At worst, someone reading your email will get a free token that you've just paid for, But, that's literally the worst that could happen.
Hope this helps.
Re: Concerns re: distribution of tokens
HTTP data is sent over the message layer, whereas TLS works on, well, the Transport Layer. That's why they don't have anything to do with each other, in the same way that (as for emails) GPG ≠ TLS.parityboy wrote: In the same way - for example - your username and password for logging into a website have nothing to do with the SSL encryption between the browser and the web server.
But Username/PW is to OpenVPN as public keys/certificates are to TLS. (roughly)
Are you implying that if someone stole my VPN key (regardless of provider) they still can't decrypt intercepted traffic?
Re: Concerns re: distribution of tokens
That's exactly what I'm saying. OpenVPN is a protocol which uses TLS 1.2 for packet encryption. Username/password for OpenVPN is no different than username/password for a website, in that a correct set of credentials will grant you access to a resource - in the case of OpenVPN, that resource is its ability to decrypt your traffic sent through the tunnel, route it to where it needs to go and then reverse the process for the replies.rc4_lol wrote:parityboy wrote:
Are you implying that if someone stole my VPN key (regardless of provider) they still can't decrypt intercepted traffic?
If you look through a Cryptostorm config file, you will notice the inline certificate - this is the public key of the exit nodes and is used by the TLS key negotiation phase.
I suggest you do a little more research into VPNs and how they work.

Re: Concerns re: distribution of tokens
Hey thanks!
Sorry I made an ass of myself too...
Sorry I made an ass of myself too...
Re: Concerns re: distribution of tokens
@OP
No problem.
It's far better to ask and learn, than to live in ignorance. 
No problem.


Re: Concerns re: distribution of tokens
Im interested in knowing more methods to get tokens with plausible deniability xD
Any ideas...? (aside from using PGP in symmetric mode ie protecting with secret passphrase ??)
Any ideas...? (aside from using PGP in symmetric mode ie protecting with secret passphrase ??)
Re: Concerns re: distribution of tokens
Why would you do this? In terms of deniability, just use a burner email, create a PGP key pair for it and use that email address when contacting a token reseller. Obviously it would help to only access that email address from CS or Tor.nonmalleable wrote:Im interested in knowing more methods to get tokens with plausible deniability xD
Any ideas...? (aside from using PGP in symmetric mode ie protecting with secret passphrase ??)
Of course, paying for the token would have to be equally as deniable.
