Concerns re: distribution of tokens

[rc4_lol]

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.

[nonmalleable]

Hmm.. any ideas to this? Since encrypted emails when at rest or after deletion are still outside our direct control.

[rc4_lol]

Hmm.. any ideas to this? [...]

What do you mean?

[parityboy]

@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.

[rc4_lol]

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.

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.
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?

[parityboy]

Are you implying that if someone stole my VPN key (regardless of provider) they still can't decrypt intercepted traffic?

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.

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.

[rc4_lol]

Hey thanks!

Sorry I made an ass of myself too...

[parityboy]

@OP

No problem. It's far better to ask and learn, than to live in ignorance.

[nonmalleable]

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 ??)

[parityboy]

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 ??)

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.

Of course, paying for the token would have to be equally as deniable.