On Wednesday, 28 August 2013 17:04:38 UTC+12, krolaw wrote:
Please forgive my ignorance here, but the box functions appear to require
both public and private keys to encrypt and decrypt.
Ah, figured out that the you combine public-client, private-server keys at
one end and private-client, public-server keys at the other....makes a lot
more sense now :-)
On Thursday, 29 August 2013 09:49:11 UTC+12, agl wrote:
If you are passing data to a third-party (the client systems) that you
don't control then you might be able to simply use secret-key cryptography
with a shared key between the encryption and decryption parts. (i.e.
I was thinking if I can't figure out the public key cryptography, then a
shared key would still meet my requirements, mostly. I guess I was trying
to avoid the possibility of extracting a key from a copy of the service
software and generating keys for that service....however, I admit it's
pretty unlikely as the service software isn't released and only runs on our
In order to use public key cryptography (nacl/box) you can generate a
random public/private keypair when encrypting and include the public key
with the ciphertext for the decryption. This is called ElGamal encryption.
The generated public/private keypair may be reused for several different
encryptions, but the nonce must be strongly random. (I.e. read the nonce
The nonce is a bit of a sticky point, as I'm trying to keep the tokens
short, and the nonce would have to transmitted with the token (or be part
of token - like a prefix). The token is only used for authentication and
would have a max life of a few days.
Anyway, you've been a great help and given me lots to think about.
Thanks for your time.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.