Re: lightweight encryption of text file

Discussion in 'Python' started by geremy condra, Jan 10, 2010.

  1. Not sure why in the world you would homebrew something like this- a
    small dependency isn't that bad, and aes can be pretty simple to use.
    Might as well go for the industrial strength approach.

    Geremy Condra
     
    geremy condra, Jan 10, 2010
    #1
    1. Advertising

  2. geremy condra

    Paul Rubin Guest

    geremy condra <> writes:
    > Not sure why in the world you would homebrew something like this- a
    > small dependency isn't that bad, and aes can be pretty simple to use.
    > Might as well go for the industrial strength approach.


    In my experience, 1) small dependencies ARE that bad, since they mean
    you have to develop and test on every platform that you want your code
    to run on; 2) using a serious library requires quite a bit of knowledge
    and decision-making which not everyone is equipped to do. "AES" is not
    so simple to use unless you know what you're doing in terms of modes,
    nonces, etc. Having supported this kind of package in a commercial
    setting in the past, IMO, for the sort of (common) application in
    question, it's best to keep things as simple as possible and supply a
    single interface that provides encryption, authentication, and random
    initialization all in one call. The cost is a little bit of ciphertext
    bloat, but it prevents all kinds of security failures frequently
    overlooked by novices.

    I'd like it a lot if the Python stdlib could include a serious
    cryptography module. That was rejected for regulatory reasons several
    years ago, but maybe things are changing enough that the issue can be
    revisited sometime.
     
    Paul Rubin, Jan 10, 2010
    #2
    1. Advertising

  3. geremy condra

    Nobody Guest

    On Sun, 10 Jan 2010 12:26:05 -0800, Paul Rubin wrote:

    > I'd like it a lot if the Python stdlib could include a serious
    > cryptography module.


    And I'd like a truckload of gold ;)

    Right now, even asking for HTTPS support is too much to ask. Heck,
    even asking for the fake HTTPS support to be identified as such is too
    much, apparently.
     
    Nobody, Jan 11, 2010
    #3
  4. geremy condra

    Steve Holden Guest

    Nobody wrote:
    > On Sun, 10 Jan 2010 12:26:05 -0800, Paul Rubin wrote:
    >
    >> I'd like it a lot if the Python stdlib could include a serious
    >> cryptography module.

    >
    > And I'd like a truckload of gold ;)
    >
    > Right now, even asking for HTTPS support is too much to ask. Heck,
    > even asking for the fake HTTPS support to be identified as such is too
    > much, apparently.
    >

    No, Paul, nobody will complain if you *ask* ...

    A question I've been asking myself quite a lot recently is how the PSF
    could, were funding to be available, direct the development of Python in
    specific directions, and what those directions should be. Unfortunately
    there are probably as many answers as Python programmers in terms of the
    priorities to be adopted.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
    Holden Web LLC http://www.holdenweb.com/
    UPCOMING EVENTS: http://holdenweb.eventbrite.com/
     
    Steve Holden, Jan 11, 2010
    #4
  5. geremy condra

    Paul Rubin Guest

    Steve Holden <> writes:
    >> Right now, even asking for HTTPS support is too much to ask. Heck,
    >> even asking for the fake HTTPS support to be identified as such is too
    >> much, apparently.
    >>

    > No, Paul, nobody will complain if you *ask* ...


    Er, that wasn't me...

    > A question I've been asking myself quite a lot recently is how the PSF
    > could, were funding to be available, direct the development of Python in
    > specific directions,...


    Crypto in the stdlib is not a matter of funding or (technical)
    priorities. It's a policy issue; the maintainers were (at least as of a
    few years ago) concerned about legal restrictions on crypto in some
    jurisdictions causing problems with distributing Python if it included
    crypto. I know that other systems (Java, Mozilla, etc) include crypto
    but they may have had to jump through some hoops for that purpose.
     
    Paul Rubin, Jan 11, 2010
    #5
  6. geremy condra

    Steve Holden Guest

    Paul Rubin wrote:
    > Steve Holden <> writes:
    >>> Right now, even asking for HTTPS support is too much to ask. Heck,
    >>> even asking for the fake HTTPS support to be identified as such is too
    >>> much, apparently.
    >>>

    >> No, Paul, nobody will complain if you *ask* ...

    >
    > Er, that wasn't me...
    >

    Oh sorry, no more it was.

    >> A question I've been asking myself quite a lot recently is how the PSF
    >> could, were funding to be available, direct the development of Python in
    >> specific directions,...

    >
    > Crypto in the stdlib is not a matter of funding or (technical)
    > priorities. It's a policy issue; the maintainers were (at least as of a
    > few years ago) concerned about legal restrictions on crypto in some
    > jurisdictions causing problems with distributing Python if it included
    > crypto. I know that other systems (Java, Mozilla, etc) include crypto
    > but they may have had to jump through some hoops for that purpose.
    >

    There are administrative hoops to jump through still in the US to export
    cryptographic code. Further, if the standard distribution were to
    include it then the requirements of the US government do still come into
    play, and it would be a pain to have to have people downloading the
    software certify (for example) that they weren't intending to re-export
    it to a "prohibited" country.

    We can get around some of these issues by retaining the hosting on
    mainland Europe rather than in the USA, but these issues do demand
    careful study which apparently nobody really has time for at present.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
    Holden Web LLC http://www.holdenweb.com/
    UPCOMING EVENTS: http://holdenweb.eventbrite.com/
     
    Steve Holden, Jan 11, 2010
    #6
  7. On Sun, Jan 10, 2010 at 3:26 PM, Paul Rubin <> wrote:
    > geremy condra <> writes:
    >> Not sure why in the world you would homebrew something like this- a
    >> small dependency isn't that bad, and aes can be pretty simple to use.
    >> Might as well go for the industrial strength approach.

    >
    > In my experience, 1) small dependencies ARE that bad, since they mean
    > you have to develop and test on every platform that you want your code
    > to run on;


    And having no dependencies frees you from the burden of testing
    where your software will be deployed? I don't think so.

    > 2) using a serious library requires quite a bit of knowledge
    > and decision-making which not everyone is equipped to do.


    Homebrewing is not a good solution to the problem of being
    ignorant of modern cryptography.

    > "AES" is not so simple to use unless you know what you're doing in
    > terms of modes, nonces, etc.


    Seems pretty simple to me- use AES 192, don't use ECB mode, and
    use your library of choice's key strengthening utilities. Even blatantly
    ignoring that advice would still probably give you better results than
    homebrewing though, so I don't really see the issue here.

    > Having supported this kind of package in a commercial
    > setting in the past, IMO, for the sort of (common) application in
    > question, it's best to keep things as simple as possible and supply a
    > single interface that provides encryption, authentication, and random
    > initialization all in one call.  The cost is a little bit of ciphertext
    > bloat, but it prevents all kinds of security failures frequently
    > overlooked by novices.
    >
    > I'd like it a lot if the Python stdlib could include a serious
    > cryptography module.  That was rejected for regulatory reasons several
    > years ago, but maybe things are changing enough that the issue can be
    > revisited sometime.


    I agree. I inquired about it not too long ago on python-ideas; little
    serious discussion ensued.

    Geremy Condra
     
    geremy condra, Jan 11, 2010
    #7
  8. geremy condra

    Paul Rubin Guest

    geremy condra <> writes:
    > And having no dependencies frees you from the burden of testing
    > where your software will be deployed? I don't think so.


    If you just use the stdlib and are a bit careful about OS dependent
    features, your code can run pretty much everywhere. More to the point,
    if (say) you develop a pure Python app on Linux and a Windows user
    reports a problem, you can probably straighten it out without having to
    actually use a Windows development system. If you need C extensions you
    need Windows compilers.

    >> 2) using a serious library requires quite a bit of knowledge
    >> and decision-making which not everyone is equipped to do.

    >
    > Homebrewing is not a good solution to the problem of being
    > ignorant of modern cryptography.


    Not sure what you're getting at. If you're referring to p3.py as a
    homebrew algorithm designed by someone ignorant, I don't think that is
    accurate. I've been a fulltime crypto developer, and p3.py was reviewed
    by several experts on sci.crypt who all felt that its design is sound.
    I don't claim it's suitable for high-value data (stick with something
    standards-conformant for that) but it was designed as a replacement for
    the now-defunct rotor module, and is just about certainly better in
    every regard. Its only cryptographic assumption is that SHA1(key+X) is
    a pseudorandom function for fixed length X. That is not a certified
    characteristic of SHA1, but the HMAC standard (RFC 2104) is based on the
    same assumption (see Krawczyk's paper cited in the RFC). I'd go as far
    as to say that it is just about certainly better than RC4, which has
    well-known distinguishers of quite low complexity.

    >> "AES" is not so simple to use unless you know what you're doing in
    >> terms of modes, nonces, etc.

    >
    > Seems pretty simple to me- use AES 192, don't use ECB mode, and
    > use your library of choice's key strengthening utilities.


    That does not address any questions of authentication, ciphertext
    malleability, IV generation, etc. p3.py handles all of that with no
    fuss imposed on the user. Really, p3.py was written because the same
    basic desire (simple, pure-Python encryption) kept coming up over and
    over in my own code and others', and it really seems to address the
    constraints about as well as anything I've been able to think of.
     
    Paul Rubin, Jan 11, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kelvin
    Replies:
    2
    Views:
    584
    Andrew Balmos (abalmos)
    Nov 9, 2004
  2. MS News
    Replies:
    2
    Views:
    342
    MS News
    Aug 1, 2003
  3. SUPER KOOL 223
    Replies:
    0
    Views:
    461
    SUPER KOOL 223
    Jul 29, 2003
  4. Daniel Fetchinson

    lightweight encryption of text file

    Daniel Fetchinson, Jan 8, 2010, in forum: Python
    Replies:
    16
    Views:
    1,654
  5. Anthra Norell

    Re: lightweight encryption of text file

    Anthra Norell, Jan 11, 2010, in forum: Python
    Replies:
    4
    Views:
    193
    John Bokma
    Jan 11, 2010
Loading...

Share This Page