FAQ
Hello,

The current crypto module contains an enumeration (crypto.Hash) which
allows hash-type independent code to be written. Wouldn't it be worthwhile
to implement this same functionality for ciphers?

E.g. I have a protocol (STS) which uses a symmetric cipher, but doesn't
really care which. Now I can either hard-code AES, have a load of separate
functions for AES/DES/etc or insert some custom enum/selector (nicest).

Would the devs be interested in a similar selector as the hash one in
crypto for ciphers?

Have a nice day,
Peter

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

  • Damian Gryski at Mar 11, 2013 at 7:00 pm
    Block ciphers implement the cipher.Block interface. That might help your design.

    http://godoc.org/crypto/cipher#Block

    Damian

    --
    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.
  • Péter Szilágyi at Mar 11, 2013 at 8:58 pm
    Yes, that is indeed my design for the moment, but I was considering taking
    it one step further: instead of writing

    import "crypto"

    import "crypto/aes"


    doSomeStuff(aes.New, crypto.SHA256)


    I could say

    import "crypto"

    doSomeStuff(crypto.AES192, crypto.SHA256)


    so that it would remain consistent with the hash registration mechanism.


    On Mon, Mar 11, 2013 at 8:00 PM, Damian Gryski wrote:

    Block ciphers implement the cipher.Block interface. That might help your
    design.

    http://godoc.org/crypto/cipher#Block

    Damian

    --
    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 Mar 12, 2013 at 4:56 pm

    On Monday, March 11, 2013 4:52:42 PM UTC-4, Péter Szilágyi wrote:

    so that it would remain consistent with the hash registration mechanism.
    Hash functions are both more uniform (ciphers have Stream and Block) and
    more numerous. We also needed a way to name a specific hash function, say
    for crypto/rsa to know which ASN.1 padding to use in PKCS#1 v1.5. Because
    of this, we have the hash registry.

    The motivation for a cipher registry is less compelling and, although you
    aren't the first to request it, it's not obvious how it would work. Would
    there be two registries (Stream and Block and, in the future, AEAD?), or a
    single registry to interface{} with the user expected to cast? The hash
    registry avoids packages having to import every hash function in order to
    support them, but AES dominates currently so that's much less of a problem
    for ciphers.


    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.
  • Péter Szilágyi at Mar 12, 2013 at 5:13 pm
    Fair enough :)

    On Tue, Mar 12, 2013 at 5:56 PM, agl wrote:
    On Monday, March 11, 2013 4:52:42 PM UTC-4, Péter Szilágyi wrote:

    so that it would remain consistent with the hash registration mechanism.
    Hash functions are both more uniform (ciphers have Stream and Block) and
    more numerous. We also needed a way to name a specific hash function, say
    for crypto/rsa to know which ASN.1 padding to use in PKCS#1 v1.5. Because
    of this, we have the hash registry.

    The motivation for a cipher registry is less compelling and, although you
    aren't the first to request it, it's not obvious how it would work. Would
    there be two registries (Stream and Block and, in the future, AEAD?), or a
    single registry to interface{} with the user expected to cast? The hash
    registry avoids packages having to import every hash function in order to
    support them, but AES dominates currently so that's much less of a problem
    for ciphers.


    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.

    --
    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
postedMar 11, '13 at 4:18p
activeMar 12, '13 at 5:13p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase