Elliptic curve cryptography

[krolaw]

Whilst I see how to sign data using elliptic curves (crypto/ecdsa), I can't see how to encrypt data using elliptic curve keys.  Can someone point me in the right direction?

Thanks.

[George Shammas]

Most likely because ecdsa can only sign and not encrypt. This is true for every implementation of ecdsa as its a limitation of ecdsa.

On Aug 24, 2013 6:17 AM, "krolaw" <kro...@gmail.com> wrote:

Whilst I see how to sign data using elliptic curves (crypto/ecdsa), I can't see how to encrypt data using elliptic curve keys.  Can someone point me in the right direction?

Thanks.

--
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 golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[alan...@gmail.com]

On Saturday, August 24, 2013 6:17:30 AM UTC-4, krolaw wrote:

Whilst I see how to sign data using elliptic curves (crypto/ecdsa), I can't see how to encrypt data using elliptic curve keys.  Can someone point me in the right direction?

see go.crypto/nacl/secretbox or, in general, one can implement Diffie-Hellman with the ScalarMult call for encryption.

Cheers

AGL

[agl]

On Saturday, August 24, 2013 6:17:30 AM UTC-4, krolaw wrote:

Whilst I see how to sign data using elliptic curves (crypto/ecdsa), I can't see how to encrypt data using elliptic curve keys.  Can someone point me in the right direction?

See go.crypto/nacl/box or, in general, you can implement Diffie-Hellman with the ScalarMult call.

Cheers

AGL 

[krolaw]

Thanks for the info on box (and secretbox).

Please forgive my ignorance here, but the box functions appear to require both public and private keys to encrypt and decrypt.  I'm wanting to have my system create tokens (encrypted data by private key) provided to client systems (that I don't control), to use with services (that I do control) that use a public key to decrypt it.  My interest in elliptic curves instead of say RSA is comes down to key/block/token size for a reasonable level of security.

Apologies as I should have made my intentions absolutely clear to start with.

Thanks again.

[agl]

On Wednesday, August 28, 2013 1:04:38 AM UTC-4, krolaw wrote:

Please forgive my ignorance here, but the box functions appear to require both public and private keys to encrypt and decrypt.  I'm wanting to have my system create tokens (encrypted data by private key) provided to client systems (that I don't control), to use with services (that I do control) that use a public key to decrypt it.  My interest in elliptic curves instead of say RSA is comes down to key/block/token size for a reasonable level of security.

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. nacl/secretbox.)

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 from crypto.rand.Reader.)

Cheers

AGL

[krolaw]

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. nacl/secretbox.)

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

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 from crypto.rand.Reader.)

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.

[krolaw]

Looks like shared keys are the answer is as I thought (wrongly) that elliptic curves used asymmetric keys for encrypted/decryption and RSA is just too big.

Many thanks to those who responded.

Cheers.

[Adam Langley]

On Wed, Aug 28, 2013 at 6:39 PM, krolaw <kro...@gmail.com> wrote:
> 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.

The nonce size can be reduced by fixing some number of the bytes to be
zero and only transmitting the non-zero bytes. The number of non-zero
bytes must be sufficient that the probability of a repeat is
negligible.


Cheers

AGL