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

Search Discussions

  • George Shammas at Aug 24, 2013 at 5:08 pm
    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" 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Agl at Aug 24, 2013 at 8:38 pm

    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Krolaw at Aug 28, 2013 at 5:04 am
    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.
    On Sunday, 25 August 2013 08:38:27 UTC+12, agl wrote:

    See go.crypto/nacl/box or, in general, you can implement Diffie-Hellman
    with the ScalarMult call.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Aug 28, 2013 at 3:22 pm
    that use a public key to decrypt it
    It doesn't make sense to use a public key to decrypt something since, by definition, a public key is publicly known.

    Perhaps you're thinking of message authentication (signing).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Agl at Aug 28, 2013 at 9:49 pm

    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Krolaw at Aug 28, 2013 at 10:39 pm

    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Krolaw at Aug 28, 2013 at 10:54 pm
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Adam Langley at Aug 28, 2013 at 10:58 pm

    On Wed, Aug 28, 2013 at 6:39 PM, krolaw 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alangley at Aug 24, 2013 at 8:43 pm

    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

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 24, '13 at 10:17a
activeAug 28, '13 at 10:58p
posts10
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase