HIFN devices, crypto and userland - BSD

This is a discussion on HIFN devices, crypto and userland - BSD ; Recently I posted a lonely thread where I thrashed out some PPPoE issues. One of the conversations that resulted was a reminder of the PCI HIFN-based devices from Soekris that could be used to speed up what is now processor-bound ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: HIFN devices, crypto and userland

  1. HIFN devices, crypto and userland

    Recently I posted a lonely thread where I thrashed out some PPPoE
    issues. One of the conversations that resulted was a reminder of the
    PCI HIFN-based devices from Soekris that could be used to speed up what
    is now processor-bound crypto stuff I might be doing in the future.

    Well, processor-bound on the old box I have. The new VIA box seems
    pretty speedy, actually.

    But, since I have exactly one PCI slot on the box, and it is not being
    used for anything, my curiosity was piqued. Would such a device assist
    in a useful manner (i.e., be more than a good pool of entropy for a
    PRNG) for those of us not running ipsec?

    So, I dug into it a bit by reading the mail list archives, various man
    pages and a little of the code. I'm not entirely sure how all the
    various levels fit together, but my understanding is that, for the
    algorithms supported, things like OpenSSH tools _will_ benefit from the
    hifn device. My logic (such as it is) is as follows:

    - hifn(4) provides specific hardware support via crypto(4)
    - OpenSSL provides much of the crypto support for userland stuff, and
    OpenSSL uses crypto(4)
    - OpenSSH (and others) depend on OpenSSL for crypto services

    So, for those symmetric algorithms used in (say) OpenSSL that are
    supported by the hardware, the device abstraction will assist with the
    math. This includes the actual encryption work, as well as the hashing
    and message authentication (again, depending on the algorithm).
    Furthermore, this implies that other userland stuff like GnuPG will not
    necessarily benefit (and even then, only for the symmetric stuff gpg
    does, of course), except perhaps that it will have a better random source.

    That is, my understanding is that an app has to use the kernel crypto(9)
    API and ask for hardware support for a session (which then goes through
    crypto(4) and so on...) Unless GnuPG (or whatever) does this, we won't
    get the hardware support.

    Is this an accurate characterization of the current state of the world?

    I'm not about to run out and order a Soekris hifn device or anything,
    but I am curious about what potential benefits it could give me.

    If I missed a specific thread on one of the mail lists that specifically
    deals with this, please feel free to let me know.

  2. Re: HIFN devices, crypto and userland

    "void * clvrmnky()" wrote:
    > Recently I posted a lonely thread where I thrashed out some PPPoE
    > issues. One of the conversations that resulted was a reminder of the
    > PCI HIFN-based devices from Soekris that could be used to speed up what
    > is now processor-bound crypto stuff I might be doing in the future.
    >
    > Well, processor-bound on the old box I have. The new VIA box seems
    > pretty speedy, actually.
    >
    > But, since I have exactly one PCI slot on the box, and it is not being
    > used for anything, my curiosity was piqued. Would such a device assist
    > in a useful manner (i.e., be more than a good pool of entropy for a
    > PRNG) for those of us not running ipsec?
    >
    > So, I dug into it a bit by reading the mail list archives, various man
    > pages and a little of the code. I'm not entirely sure how all the
    > various levels fit together, but my understanding is that, for the
    > algorithms supported, things like OpenSSH tools _will_ benefit from the
    > hifn device. My logic (such as it is) is as follows:
    >
    > - hifn(4) provides specific hardware support via crypto(4)
    > - OpenSSL provides much of the crypto support for userland stuff, and
    > OpenSSL uses crypto(4)
    > - OpenSSH (and others) depend on OpenSSL for crypto services
    >
    > So, for those symmetric algorithms used in (say) OpenSSL that are
    > supported by the hardware, the device abstraction will assist with the
    > math. This includes the actual encryption work, as well as the hashing
    > and message authentication (again, depending on the algorithm).
    > Furthermore, this implies that other userland stuff like GnuPG will not
    > necessarily benefit (and even then, only for the symmetric stuff gpg
    > does, of course), except perhaps that it will have a better random source.
    >
    > That is, my understanding is that an app has to use the kernel crypto(9)
    > API and ask for hardware support for a session (which then goes through
    > crypto(4) and so on...) Unless GnuPG (or whatever) does this, we won't
    > get the hardware support.
    >
    > Is this an accurate characterization of the current state of the world?
    >
    > I'm not about to run out and order a Soekris hifn device or anything,
    > but I am curious about what potential benefits it could give me.
    >
    > If I missed a specific thread on one of the mail lists that specifically
    > deals with this, please feel free to let me know.


    This is essentially correct. The point about GnuPG, though, is not
    always relevant; I don't know what you use it for, but if you - like me
    - use it only for normal e-mail messages, encryption or decryption speed
    without crypto hardware is plenty fast.

    The same applies, to some extent, to SSH. I do occasionally copy large
    chunks of data, but other than that, very little speed is needed (though
    low latency is nice).

    The most benefit is had by people running crypto over large chunks of
    data - which pretty accurately describes your average VPN.

    Joachim

  3. Re: HIFN devices, crypto and userland

    jKILLSPAM.schipper@math.uu.nl wrote:
    > "void * clvrmnky()" wrote:
    >> Recently I posted a lonely thread where I thrashed out some PPPoE
    >> issues. One of the conversations that resulted was a reminder of the
    >> PCI HIFN-based devices from Soekris that could be used to speed up what
    >> is now processor-bound crypto stuff I might be doing in the future.
    >>
    >> Well, processor-bound on the old box I have. The new VIA box seems
    >> pretty speedy, actually.
    >>
    >> But, since I have exactly one PCI slot on the box, and it is not being
    >> used for anything, my curiosity was piqued. Would such a device assist
    >> in a useful manner (i.e., be more than a good pool of entropy for a
    >> PRNG) for those of us not running ipsec?
    >>
    >> So, I dug into it a bit by reading the mail list archives, various man
    >> pages and a little of the code. I'm not entirely sure how all the
    >> various levels fit together, but my understanding is that, for the
    >> algorithms supported, things like OpenSSH tools _will_ benefit from the
    >> hifn device. My logic (such as it is) is as follows:
    >>
    >> - hifn(4) provides specific hardware support via crypto(4)
    >> - OpenSSL provides much of the crypto support for userland stuff, and
    >> OpenSSL uses crypto(4)
    >> - OpenSSH (and others) depend on OpenSSL for crypto services
    >>
    >> So, for those symmetric algorithms used in (say) OpenSSL that are
    >> supported by the hardware, the device abstraction will assist with the
    >> math. This includes the actual encryption work, as well as the hashing
    >> and message authentication (again, depending on the algorithm).
    >> Furthermore, this implies that other userland stuff like GnuPG will not
    >> necessarily benefit (and even then, only for the symmetric stuff gpg
    >> does, of course), except perhaps that it will have a better random source.
    >>
    >> That is, my understanding is that an app has to use the kernel crypto(9)
    >> API and ask for hardware support for a session (which then goes through
    >> crypto(4) and so on...) Unless GnuPG (or whatever) does this, we won't
    >> get the hardware support.
    >>
    >> Is this an accurate characterization of the current state of the world?
    >>
    >> I'm not about to run out and order a Soekris hifn device or anything,
    >> but I am curious about what potential benefits it could give me.
    >>
    >> If I missed a specific thread on one of the mail lists that specifically
    >> deals with this, please feel free to let me know.

    >
    > This is essentially correct. The point about GnuPG, though, is not
    > always relevant; I don't know what you use it for, but if you - like me
    > - use it only for normal e-mail messages, encryption or decryption speed
    > without crypto hardware is plenty fast.
    >
    > The same applies, to some extent, to SSH. I do occasionally copy large
    > chunks of data, but other than that, very little speed is needed (though
    > low latency is nice).
    >
    > The most benefit is had by people running crypto over large chunks of
    > data - which pretty accurately describes your average VPN.
    >

    Of course. Perhaps I was not clear in my original post, but my comments
    were not about whether or not the performance gains for arbitrary
    userland process were obvious or warranted, but whether or not arbitrary
    userland processes would even use the hardware.

    i.e., to quote myself, "Would such a device assist in a useful manner".

    While the biggest gain for this hardware would be stuff like ipsec, my
    musings are about whether something like https, GPG or OpenSSH would
    even have access to the hardware device. My conclusions are "sometimes"
    depending on (obviously) the algorithm used and (less obvious to me) how
    that application or process asks for crypto services. Further to this
    is "with diminishing returns for trivial uses like GnuPG", but this was
    sort of beside my point.

    That is, I was not complaining that GnuPG or OpenSSH were not useful. I
    was using them as examples of applications that might or might not
    benefit from hardware support, where "benefit" is not really defined
    beyond "bits will flow in the hardware device as a result"

    More specifically, I'm idly trying to determine if the HTTPS/webDAV app
    I'm constructing would benefit _at all_ from such hardware. This is not
    quite as useful an application of the hardware as (say) ipsec, but might
    be worth investigating.

  4. Re: HIFN devices, crypto and userland

    "void * clvrmnky()" wrote in message
    news:wjeXf.16602$43.11572@nnrp.ca.mci.com!nnrp1.uu net.ca...
    >
    > More specifically, I'm idly trying to determine if the HTTPS/webDAV app
    > I'm constructing would benefit _at all_ from such hardware. This is not
    > quite as useful an application of the hardware as (say) ipsec, but might
    > be worth investigating.


    Oh. Server-side? I had thought you were talking about client-side.

    Steve
    http://www.fivetrees.com



  5. Re: HIFN devices, crypto and userland

    "void * clvrmnky()" wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >> "void * clvrmnky()" wrote:
    >>> Recently I posted a lonely thread where I thrashed out some PPPoE
    >>> issues. One of the conversations that resulted was a reminder of the
    >>> PCI HIFN-based devices from Soekris that could be used to speed up what
    >>> is now processor-bound crypto stuff I might be doing in the future.
    >>>
    >>> Well, processor-bound on the old box I have. The new VIA box seems
    >>> pretty speedy, actually.
    >>>
    >>> But, since I have exactly one PCI slot on the box, and it is not being
    >>> used for anything, my curiosity was piqued. Would such a device assist
    >>> in a useful manner (i.e., be more than a good pool of entropy for a
    >>> PRNG) for those of us not running ipsec?
    >>>
    >>> So, I dug into it a bit by reading the mail list archives, various man
    >>> pages and a little of the code. I'm not entirely sure how all the
    >>> various levels fit together, but my understanding is that, for the
    >>> algorithms supported, things like OpenSSH tools _will_ benefit from the
    >>> hifn device. My logic (such as it is) is as follows:
    >>>
    >>> - hifn(4) provides specific hardware support via crypto(4)
    >>> - OpenSSL provides much of the crypto support for userland stuff, and
    >>> OpenSSL uses crypto(4)
    >>> - OpenSSH (and others) depend on OpenSSL for crypto services
    >>>
    >>> So, for those symmetric algorithms used in (say) OpenSSL that are
    >>> supported by the hardware, the device abstraction will assist with the
    >>> math. This includes the actual encryption work, as well as the hashing
    >>> and message authentication (again, depending on the algorithm).
    >>> Furthermore, this implies that other userland stuff like GnuPG will not
    >>> necessarily benefit (and even then, only for the symmetric stuff gpg
    >>> does, of course), except perhaps that it will have a better random source.
    >>>
    >>> That is, my understanding is that an app has to use the kernel crypto(9)
    >>> API and ask for hardware support for a session (which then goes through
    >>> crypto(4) and so on...) Unless GnuPG (or whatever) does this, we won't
    >>> get the hardware support.
    >>>
    >>> Is this an accurate characterization of the current state of the world?
    >>>
    >>> I'm not about to run out and order a Soekris hifn device or anything,
    >>> but I am curious about what potential benefits it could give me.
    >>>
    >>> If I missed a specific thread on one of the mail lists that specifically
    >>> deals with this, please feel free to let me know.

    >>
    >> This is essentially correct. The point about GnuPG, though, is not
    >> always relevant; I don't know what you use it for, but if you - like me
    >> - use it only for normal e-mail messages, encryption or decryption speed
    >> without crypto hardware is plenty fast.
    >>
    >> The same applies, to some extent, to SSH. I do occasionally copy large
    >> chunks of data, but other than that, very little speed is needed (though
    >> low latency is nice).
    >>
    >> The most benefit is had by people running crypto over large chunks of
    >> data - which pretty accurately describes your average VPN.
    >>

    > Of course. Perhaps I was not clear in my original post, but my comments
    > were not about whether or not the performance gains for arbitrary
    > userland process were obvious or warranted, but whether or not arbitrary
    > userland processes would even use the hardware.
    >
    > i.e., to quote myself, "Would such a device assist in a useful manner".
    >
    > While the biggest gain for this hardware would be stuff like ipsec, my
    > musings are about whether something like https, GPG or OpenSSH would
    > even have access to the hardware device. My conclusions are "sometimes"
    > depending on (obviously) the algorithm used and (less obvious to me) how
    > that application or process asks for crypto services. Further to this
    > is "with diminishing returns for trivial uses like GnuPG", but this was
    > sort of beside my point.
    >
    > That is, I was not complaining that GnuPG or OpenSSH were not useful. I
    > was using them as examples of applications that might or might not
    > benefit from hardware support, where "benefit" is not really defined
    > beyond "bits will flow in the hardware device as a result"
    >
    > More specifically, I'm idly trying to determine if the HTTPS/webDAV app
    > I'm constructing would benefit _at all_ from such hardware. This is not
    > quite as useful an application of the hardware as (say) ipsec, but might
    > be worth investigating.


    The HTTPS server is likely to use OpenSSL, which uses hardware crypto
    when available. So yes, for your definition of 'benefit', there would be
    a benefit.

    Joachim

+ Reply to Thread