rotor replacement

Discussion in 'Python' started by Reed L. O'Brien, Jan 19, 2005.

  1. I see rotor was removed for 2.4 and the docs say use an AES module
    provided separately... Is there a standard module that works alike or
    an AES module that works alike but with better encryption?

    cheers,
    reed
    Reed L. O'Brien, Jan 19, 2005
    #1
    1. Advertising

  2. Reed L. O'Brien

    Paul Rubin Guest

    "Reed L. O'Brien" <> writes:
    > I see rotor was removed for 2.4 and the docs say use an AES module
    > provided separately... Is there a standard module that works alike or
    > an AES module that works alike but with better encryption?


    If you mean a module in the distribution, the answer is no, for
    political reasons.

    There are a number of AES modules available on the net. Most are C
    extension modules which means you need to compile them, and if you
    want to deploy them widely, you need binaries for every target platform.
    There's a few pure-Python AES implementations but they are verrry slow.

    Here's something written in Python that uses the built-in sha1 module
    as a crypto primitive. Its security should be better than rotor and
    performance is reasonable for most applications:

    http://www.nightsong.com/phr/crypto/p3.py
    Paul Rubin, Jan 19, 2005
    #2
    1. Advertising

  3. Reed L. O'Brien

    Robin Becker Guest

    Paul Rubin wrote:
    > "Reed L. O'Brien" <> writes:
    >
    >>I see rotor was removed for 2.4 and the docs say use an AES module
    >>provided separately... Is there a standard module that works alike or
    >>an AES module that works alike but with better encryption?

    >
    >
    > If you mean a module in the distribution, the answer is no, for
    > political reasons.
    >

    ......I'm also missing the rotor module and regret that something useful
    was warned about and now removed with no plugin replacement.

    I had understood that this was because rotor was insecure, but you
    mention politics. Are other useful modules to suffer from politics?

    What exactly are/were the political reasons for rotor removal?

    I might add that the source for rotormodule is still easily obtainable
    and can be compiled trivially as an extension for Python-2.4. Does the
    Python community take a position on the sources of removed modules?
    --
    Robin Becker
    Robin Becker, Jan 19, 2005
    #3
  4. Reed L. O'Brien

    Paul Rubin Guest

    Robin Becker <> writes:
    > What exactly are/were the political reasons for rotor removal?


    Some countries have laws about cryptography software (against some
    combination of export, import, or use). The Python maintainers didn't
    want to deal with imagined legal hassles that might develop from
    including good crypto functions in the distribution. Then it became
    obvious that the same imagined hassles could also befall the rotor
    module, so that was removed.

    > I might add that the source for rotormodule is still easily obtainable
    > and can be compiled trivially as an extension for Python-2.4. Does the
    > Python community take a position on the sources of removed modules?


    Those are still free to distribute, but I'd advise against doing so
    with the rotor module unless you absolutely need it for some
    interoperability purpose. Otherwise, it's insecure and should not be
    used. The routine I posted was intended as a straightforward
    replacement for the rotor module that doesn't depend on C compilers
    and is reasonably secure. If you don't mind using C extensions,
    there's various AES modules available, plus fancier packages like
    mxCrypto.
    Paul Rubin, Jan 19, 2005
    #4
  5. Reed L. O'Brien

    Gerd Woetzel Guest

    Robin Becker <> writes:
    >Paul Rubin wrote:
    >.....I'm also missing the rotor module and regret that something useful
    >was warned about and now removed with no plugin replacement.


    Hm, yes. Here is a (rather slow) replacement:

    """This module is derived from Modules/rotormodule.c and translated
    into Python. I have appended the Copyright by Lance Ellinghouse
    below. The rotor module has been removed from the Python 2.4
    distribution because

    the rotor module uses an insecure algorithm and is deprecated.
    ==============================================================

    Of course, this does still hold. However, I think this module might
    be used and adapted for demonstration purposes and might help some
    poor users who have encrypted (or obfuscated) some old stuff with
    the rotor module and have no access to older Python versions any
    more.

    Documentation can be found in

    Python Library Reference, Guido van Rossum, Fred L. Drake, Jr., editor,
    PythonLabs, Release 2.3.4 May 20, 2004
    <http://www.python.org/doc/2.3.4/lib/module-rotor.html>

    #####################################################################
    Copyright 1994 by Lance Ellinghouse,
    Cathedral City, California Republic, United States of America.

    All Rights Reserved

    Permission to use, copy, modify, and distribute this software and its
    documentation for any purpose and without fee is hereby granted,
    provided that the above copyright notice appear in all copies and that
    both that copyright notice and this permission notice appear in
    supporting documentation, and that the name of Lance Ellinghouse
    not be used in advertising or publicity pertaining to distribution
    of the software without specific, written prior permission.

    LANCE ELLINGHOUSE DISCLAIMS ALL WARRANTIES WITH REGARD TO
    THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
    FITNESS, IN NO EVENT SHALL LANCE ELLINGHOUSE BE LIABLE FOR ANY SPECIAL,
    INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
    FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
    NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
    WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
    #####################################################################
    """

    class newrotor(object):

    def __init__(self, key, n_rotors=6):
    self.n_rotors = n_rotors
    self.setkey(key)

    def setkey(self, key):
    self.key = key
    self.rotors = None
    self.positions = [None, None]

    def encrypt(self, buf):
    # Reset (encrypt) positions and encryptmore
    self.positions[0] = None
    return self.cryptmore(buf, 0)

    def encryptmore(self, buf):
    return self.cryptmore(buf, 0)

    def decrypt(self, buf):
    # Reset decrypt positions and decryptmore
    self.positions[1] = None
    return self.cryptmore(buf, 1)

    def decryptmore(self, buf):
    return self.cryptmore(buf, 1)

    def cryptmore(self, buf, do_decrypt):
    size, nr, rotors, pos = self.get_rotors(do_decrypt)
    outbuf = []
    append = outbuf.append
    for c in map(ord, buf):
    if do_decrypt:
    # Apply decrypt rotors and xor in reverse order
    for i in xrange(nr-1,-1,-1):
    c = pos ^ rotors[c]
    else:
    # Apply xor and ecrypt rotors
    for i in xrange(nr):
    c = rotors[c ^ pos]
    append(c)

    # Advance rotors, i.e. add the (fixed) rotor increments to the
    # variable rotor positions with carry.
    # Note: In the C-implementation, the result of the carry addition
    # was stored to an "unsigned char". Hence the next carry
    # is lost if pos == size-1 and pnew >= size.
    # Masking with 0xff simulates this behavior.
    #
    pnew = 0 # (pnew >= size) works as "carry bit"
    for i in xrange(nr):
    pnew = ((pos + (pnew >= size)) & 0xff) + rotors[size]
    pos = pnew % size

    return ''.join(map(chr, outbuf))

    def get_rotors(self, do_decrypt):
    # Return a tuple (size, nr, rotors, positions) where
    # - size is the rotor size (== 256, because of 8-bit bytes)
    # - nr is the number of rotors.
    # - rotors is a tuple of nr encrypt or nr decrypt rotors
    # for do_decrypt == 0 or do_decrypt == 1 respectively.
    # - postions is a list of nr "rotor positions".
    #
    # The rotors represent the static aspect of the rotor machine which
    # is initially computed from key and fixed during en/decryption.
    # A rotor is a random permutation of range(size) extended
    # by an "increment value" in range(size).
    #
    # The followng statements hold for a tuple of encrypt rotors E and
    # and the corresponding tuple of decrypt rotors D.
    #
    # D[E[j]] == j for i in range(nr) for j in range(size)
    #
    # E[D[j]] == j for i in range(nr) for j in range(size)
    #
    # This means that the corresponding rotors E and D are
    # inverse permutations.
    # The increments are equal for the corresponding encrypt and
    # decrypt rotors and have an odd value:
    #
    # D[size] == E[size] and E[size] == 1 mod 2 and
    # 0 < E[size] < size for i in range(nr)
    #
    # The position vector represents the dynamic aspect.
    # It changes after each en/decrypted character (the rotors
    # are "advanced"). The initial position vector is also computed
    # from the key
    #
    nr = self.n_rotors
    rotors = self.rotors
    positions = self.positions[do_decrypt]

    if positions is None:
    if rotors:
    positions = list(rotors[3])
    else:
    # Generate identity permutation for 8-bit bytes plus an
    # (unused) increment value
    self.size = size = 256
    id_rotor = range(size+1)

    # Generate nr "random" initial positions and "random"
    # en/decrypt rotors from id_rotor.
    #
    rand = random_func(self.key)
    E = []
    D = []
    positions = []
    for i in xrange(nr):
    i = size
    positions.append(rand(i))
    erotor = id_rotor[:]
    drotor = id_rotor[:]
    drotor = erotor = 1 + 2*rand(i/2) # increment
    while i > 1:
    r = rand(i)
    i -= 1
    er = erotor[r]
    erotor[r] = erotor[i]
    erotor[i] = er
    drotor[er] = i
    drotor[erotor[0]] = 0
    E.append(tuple(erotor))
    D.append(tuple(drotor))
    self.rotors = rotors = (
    tuple(E), tuple(D), size, tuple(positions))
    self.positions[do_decrypt] = positions
    return rotors[2], nr, rotors[do_decrypt], positions

    def random_func(key):
    # Generate a random number generator that is "seeded" from key.
    # This algorithm is copied from Python2.3 randommodule.c.
    #
    mask = 0xffff
    x=995
    y=576
    z=767
    for c in map(ord, key):
    x = (((x<<3 | x>>13) + c) & mask)
    y = (((y<<3 | y>>13) ^ c) & mask)
    z = (((z<<3 | z>>13) - c) & mask)

    # Emulate (unintended?) cast to short
    maxpos = mask >> 1
    mask += 1
    if x > maxpos: x -= mask
    if y > maxpos: y -= mask
    if z > maxpos: z -= mask

    y |= 1 # avoid very bad seed, why not for x and z too?

    # Oh, dear, for compatibility, we must evaluate the first seed transition
    # the hard way, later it becomes much simpler
    x = 171 * (x % 177) - 2 * (x/177)
    y = 172 * (y % 176) - 35 * (y/176)
    z = 170 * (z % 178) - 63 * (z/178)
    if x < 0: x += 30269
    if y < 0: y += 30307
    if z < 0: z += 30323
    # At least all values are > 0 by now but may be greater than expected ..

    def rand(n, seed=[(x, y, z)]):
    # Return a random number 0 <= r < n
    #
    x, y, z = seed[0]
    seed[0] = ((171*x) % 30269, (172*y) % 30307, (170*z) % 30323)
    return int((x/30269.0 + y/30307.0 + z/30323.0) * n) % n

    # Original code was like this:
    # from math import floor
    # val = x/30269.0 + y/30307.0 + z/30323.0
    # val = val - floor(val)
    # if val >= 1.0:
    # val = 0.0
    # n = int(val*n) % n

    return rand[/i][/i]
    Gerd Woetzel, Jan 19, 2005
    #5
  6. Robin Becker <> wrote:
    > Paul Rubin wrote:
    > > "Reed L. O'Brien" <> writes:
    > >
    > >>I see rotor was removed for 2.4 and the docs say use an AES module
    > >>provided separately... Is there a standard module that works alike or
    > >>an AES module that works alike but with better encryption?

    > >
    > >
    > > If you mean a module in the distribution, the answer is no, for
    > > political reasons.
    > >

    > .....I'm also missing the rotor module and regret that something useful
    > was warned about and now removed with no plugin replacement.
    >
    > I had understood that this was because rotor was insecure, but you
    > mention politics. Are other useful modules to suffer from politics?
    >
    > What exactly are/were the political reasons for rotor removal?


    Presumably he is talking about crypo-export rules. In the past strong
    cryptography has been treated as munitions, and as such exporting it
    (especially from the USA) could have got you into very serious
    trouble.

    However I believe those restrictions have been lifted (the cat having
    been let out of the bag somewhat ;-), and its easy to do this for open
    source encryption software. A wade through

    http://www.bxa.doc.gov/Encryption/enc.htm

    Might be interesting.

    A case in point: the linux 2.6 kernel is chock full of crypo and comes
    with implementations of AES, ARC4, Blowfish, Cast5+6, DES, Serpent,
    Twofish, TEA, etc. The linux kernel+source surely goes everywhere
    python does so I don't think adding strong crypto modules to python is
    a problem now-a-days.

    AES in the core python library would be very useful and it would
    discourage people from writing their own crypto routines (looks easy
    but isn't!)

    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
    Nick Craig-Wood, Jan 19, 2005
    #6
  7. Reed L. O'Brien

    Fuzzyman Guest

    Thanks very much to all the folks who replied to this. I've been loking
    for pure python encryption routines for a while and found this thread
    very useful.

    There is also a pure python des implementation in 'aps' an NTLM proxy
    server.
    Regards,


    Fuzzy
    http://www.voidspace.org.uk/python/index.shtml
    Fuzzyman, Jan 19, 2005
    #7
  8. Paul Rubin wrote:
    > Robin Becker <> writes:
    >>What exactly are/were the political reasons for rotor removal?

    > Some countries have laws about cryptography software (against some
    > combination of export, import, or use).


    I understand this to be true. Since I am trying to address encryption
    in the zipfile module, and I know you actually follow a bit of the
    encryption stuff, can you answer a question or two for me?

    > The Python maintainers didn't want to deal with imagined legal hassles
    > that might develop from including good crypto functions in the
    > distribution. Then it became obvious that the same imagined hassles
    > could also befall the rotor module, so that was removed.


    Are you saying these hassles are, in fact, imaginary rather than real?
    Is this because you feel python is over-cautious about the USA, or is
    this an opinion on "essentially all countries?" This is not a quibble
    or a kvetch; I would like your understanding about the world legal
    state of dealing with encryption (which, I assure you, I won't take as
    definitive). I would hate to think someone in, for example, the UAE,
    was busted for downloading or republishing python "out-of-the-box."

    Don't get me wrong, I'd love the answer to be "sure its fine," but my
    current plans are to provide a way to connect a crypto package to
    zipfile without providing any such package myself.

    --Scott David Daniels
    Scott David Daniels, Jan 19, 2005
    #8
  9. Reed L. O'Brien

    Paul Rubin Guest

    Scott David Daniels <> writes:
    > I understand this to be true. Since I am trying to address encryption
    > in the zipfile module, and I know you actually follow a bit of the
    > encryption stuff, can you answer a question or two for me?


    Sure, I can try, so go ahead. There's more crypto expertise in
    sci.crypt though.

    Zipfile encryption is totally incompatible with the rotor module, by
    the way, and traditionally it didn't use AES. There are a couple of
    replacements for the traditional method that do use AES but that I
    think are somewhat incompatible with each other.

    > > The Python maintainers didn't want to deal with imagined legal hassles
    > > that might develop from including good crypto functions in the
    > > distribution. Then it became obvious that the same imagined hassles
    > > could also befall the rotor module, so that was removed.

    >
    > Are you saying these hassles are, in fact, imaginary rather than real?


    Well, I didn't want to say that the hassles were real, but I wasn't
    trying to insinuate quite as much as it may have sounded. Like, I
    don't drive my car at 100 mph on Main Street because I can imagine
    what would happen and it's not pretty. The imagined carnage is a good
    enough reason not to drive that way. However, I do feel that the
    Python distributors are being over-cautious, see below.

    > Is this because you feel python is over-cautious about the USA, or is
    > this an opinion on "essentially all countries?" This is not a quibble
    > or a kvetch; I would like your understanding about the world legal
    > state of dealing with encryption (which, I assure you, I won't take as
    > definitive). I would hate to think someone in, for example, the UAE,
    > was busted for downloading or republishing python "out-of-the-box."


    I think the Python maintainers were more concerned about that UAE
    situation. However, the most widely deployed encryption software is
    the SSL stack in just about every web browser (MSIE, Firefox, etc.)
    and I'm sure lots of people are using those browsers in the UAE. The
    Mozilla foundation isn't hestitating to ship the encryption as far as
    I can tell.

    See http://www.bxa.doc.gov/Encryption for the USA rules. Basically
    for a free encryption program on the web, you're supposed to notify
    the Dept. of Commerce by sending them an email when you publish it,
    telling them where they can get it (address is on that site). As far
    as anyone can tell, the DOC never does anything with those emails.
    The rules are more complicated for nonpublished commercial programs,
    crypto hardware, etc.

    > Don't get me wrong, I'd love the answer to be "sure its fine," but my
    > current plans are to provide a way to connect a crypto package to
    > zipfile without providing any such package myself.


    I'd say provide a package if you can, unless you have realistic
    concern about getting in trouble.
    Paul Rubin, Jan 19, 2005
    #9
  10. Reed L. O'Brien

    Robin Becker Guest

    Nick Craig-Wood wrote:
    > Robin Becker <> wrote:
    >
    >> Paul Rubin wrote:
    >>
    >>>"Reed L. O'Brien" <> writes:
    >>>
    >>>
    >>>>I see rotor was removed for 2.4 and the docs say use an AES module
    >>>>provided separately... Is there a standard module that works alike or
    >>>>an AES module that works alike but with better encryption?
    >>>
    >>>
    >>>If you mean a module in the distribution, the answer is no, for
    >>>political reasons.
    >>>

    >>
    >> .....I'm also missing the rotor module and regret that something useful
    >> was warned about and now removed with no plugin replacement.
    >>
    >> I had understood that this was because rotor was insecure, but you
    >> mention politics. Are other useful modules to suffer from politics?
    >>

    ....
    > Presumably he is talking about crypo-export rules. In the past strong
    > cryptography has been treated as munitions, and as such exporting it
    > (especially from the USA) could have got you into very serious
    > trouble.


    well since rotor is a german (1930's) invention it is a bit late for
    Amricans (Hollywood notwithstanding) to be worried about its export

    > However I believe those restrictions have been lifted (the cat having
    > been let out of the bag somewhat ;-), and its easy to do this for open
    > source encryption software. A wade through
    >


    --
    Robin Becker
    Robin Becker, Jan 20, 2005
    #10
  11. Reed L. O'Brien

    Robin Becker Guest

    Robin Becker wrote:

    >> Presumably he is talking about crypo-export rules. In the past strong
    >> cryptography has been treated as munitions, and as such exporting it
    >> (especially from the USA) could have got you into very serious
    >> trouble.

    >

    So Python is an American Language and must obey American Law. Luckily I
    seem to have escaped that fate.
    --
    Robin Becker
    Robin Becker, Jan 20, 2005
    #11
  12. Reed L. O'Brien

    Paul Rubin Guest

    Robin Becker <> writes:
    > > Presumably he is talking about crypo-export rules. In the past strong
    > > cryptography has been treated as munitions, and as such exporting it
    > > (especially from the USA) could have got you into very serious
    > > trouble.

    >
    > well since rotor is a german (1930's) invention it is a bit late for
    > Amricans (Hollywood notwithstanding) to be worried about its export


    1. I think the concern was not about exporting from the US, but rather
    importing into some countries that restrict the use of crypto. But
    the cat is out of the bag on that one too. Just about every web
    browser includes an SSL stack and those browsers are in use
    everywhere.

    2. It's irrelevant for the purpose of export rules how old an
    invention is or where it was invented. I don't know where machine
    guns were invented, but they're at least 100 years old and you can't
    export those without a license either. My gripe with the crypto rules
    are not about the age or nationality of crypto rotor machines (rotor
    is not a clone of the Enigma by the way; it just operates on related
    principles) but rather on the control of information in general.
    Exporting a machine gun is much different from publishing a
    description of one. Software is just a precise type of description.
    Paul Rubin, Jan 20, 2005
    #12
  13. On 19 Jan 2005 17:09:19 -0800, Paul Rubin <http://> wrote:

    >Robin Becker <> writes:
    >> > Presumably he is talking about crypo-export rules. In the past strong
    >> > cryptography has been treated as munitions, and as such exporting it
    >> > (especially from the USA) could have got you into very serious
    >> > trouble.

    >>
    >> well since rotor is a german (1930's) invention it is a bit late for
    >> Amricans (Hollywood notwithstanding) to be worried about its export

    >
    >1. I think the concern was not about exporting from the US, but rather
    >importing into some countries that restrict the use of crypto. But
    >the cat is out of the bag on that one too. Just about every web
    >browser includes an SSL stack and those browsers are in use
    >everywhere.

    Isn't the SSL dependent on OS or at least shared lib support?
    Wasn't there a default 40-bit version that was ok (weak), but you had
    to declare yourself US resident to download 128-bit support?
    I dimly recall encountering this sort of thing installing Netscape
    a long time ago, I think. Is 128 just standard now? And now that 128
    is wobbly(?), will the same thing be replayed with the ante upped?

    >
    >2. It's irrelevant for the purpose of export rules how old an
    >invention is or where it was invented. I don't know where machine
    >guns were invented, but they're at least 100 years old and you can't
    >export those without a license either. My gripe with the crypto rules
    >are not about the age or nationality of crypto rotor machines (rotor
    >is not a clone of the Enigma by the way; it just operates on related
    >principles) but rather on the control of information in general.

    I can easily conceive of information that I'd rather not see publicized
    without severe access controls. But in general I do believe in open sharing
    of free information as the most productive for everyone.

    >Exporting a machine gun is much different from publishing a
    >description of one. Software is just a precise type of description.

    Yeah, but ... ;-)

    Regards,
    Bengt Richter
    Bengt Richter, Jan 20, 2005
    #13
  14. Reed L. O'Brien

    Paul Rubin Guest

    (Bengt Richter) writes:
    > Isn't the SSL dependent on OS or at least shared lib support?


    Firefox has its own implementation. IE uses wininet which is built
    Windows. I'm not aware of any no-crypto version of Windows but even
    if there is one, the US version is running, like, everywhere.

    > Wasn't there a default 40-bit version that was ok (weak), but you had
    > to declare yourself US resident to download 128-bit support?


    That was years ago. The regulations changed since then, so they all
    have 128 bits now.

    > I dimly recall encountering this sort of thing installing Netscape
    > a long time ago, I think. Is 128 just standard now? And now that 128
    > is wobbly(?), will the same thing be replayed with the ante upped?


    128 isn't wobbly. It will be a long time before any machine can do
    2**128 operations to break a message.
    Paul Rubin, Jan 20, 2005
    #14
  15. Reed L. O'Brien

    Peter Maas Guest

    Paul Rubin schrieb:
    >>Wasn't there a default 40-bit version that was ok (weak), but you had
    >>to declare yourself US resident to download 128-bit support?

    >
    >
    > That was years ago. The regulations changed since then, so they all
    > have 128 bits now.


    Perhaps the NSA has found a way to handle 128bit in the meantime.
    But this is unlikely because there is no export regulation to ban
    512bit as far as I know :)

    --
    -------------------------------------------------------------------
    Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
    E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
    -------------------------------------------------------------------
    Peter Maas, Jan 20, 2005
    #15
  16. Reed L. O'Brien

    Robin Becker Guest

    Peter Maas wrote:
    > Paul Rubin schrieb:
    >
    >>> Wasn't there a default 40-bit version that was ok (weak), but you had
    >>> to declare yourself US resident to download 128-bit support?

    >>
    >>
    >>
    >> That was years ago. The regulations changed since then, so they all
    >> have 128 bits now.

    >
    >
    > Perhaps the NSA has found a way to handle 128bit in the meantime.
    > But this is unlikely because there is no export regulation to ban
    > 512bit as far as I know :)
    >


    Apparently factorization based crypto is on the way out anyhow (as an
    article in Scientific American is reported to claim).

    http://www.sciam.com/article.cfm?chanID=sa006&articleID=000479CD-F58C-11BE-AD0683414B7F0000&ref=rdf

    -can't wait to get my quantum computer-ly yrs-
    Robin Becker
    Robin Becker, Jan 20, 2005
    #16
  17. Reed L. O'Brien

    Paul Rubin Guest

    Robin Becker <> writes:
    > Apparently factorization based crypto is on the way out anyhow (as an
    > article in Scientific American is reported to claim).


    I haven't seen that SA article but I saw the Slashdot blurb. They
    have confused "quantum cryptography" with quantum computation, when
    they are entirely different things. Quantum cryptography (basically
    communicating a message over an optical fiber in such a way that any
    attempt to eavesdrop is supposed destroy the readability of the
    message) has been done over quite long distances, 10's of km or even
    more. Quantum computation is mostly a theoretical speculation. The
    largest quantum computer ever built held seven bits, and factored the
    number 15 into its factors 3 and 5. Building larger ones seems to
    have complexity exponential in the number of bits, which is not too
    much better than using an exponential-time algorithm on a conventional
    computer. It's not even known in theory whether quantum computing is
    possible on a significant scale. There are just some theorems about
    what properties such a computer would have, if it can exist. One of
    them, however, is being able to factor in P-time, and that caused
    lots of excitement.
    Paul Rubin, Jan 20, 2005
    #17
  18. Paul Rubin wrote:
    > Some countries have laws about cryptography software (against some
    > combination of export, import, or use). The Python maintainers didn't
    > want to deal with imagined legal hassles that might develop from
    > including good crypto functions in the distribution. Then it became
    > obvious that the same imagined hassles could also befall the rotor
    > module, so that was removed.


    Do you know this for a fact? The PSF does comply with the U.S. American
    export procedures for crypto code, and reports the crypto code in
    Python appropriately to BXA.

    Regards,
    Martin
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jan 20, 2005
    #18
  19. Reed L. O'Brien

    Guest

    "Martin v. Löwis" <> writes:
    > > Some countries have laws about cryptography software (against some
    > > combination of export, import, or use). The Python maintainers didn't
    > > want to deal with imagined legal hassles that might develop from
    > > including good crypto functions in the distribution. Then it became
    > > obvious that the same imagined hassles could also befall the rotor
    > > module, so that was removed.

    >
    > Do you know this for a fact?


    I'm going by newsgroup messages from around the time that I was
    proposing to put together a standard block cipher module for Python.

    > The PSF does comply with the U.S. American export procedures for
    > crypto code, and reports the crypto code in Python appropriately to BXA.


    Since rotor was removed, there is no crypto code in Python that needs
    reporting.
    , Jan 20, 2005
    #19
  20. ldomain wrote:
    >>Do you know this for a fact?

    >
    >
    > I'm going by newsgroup messages from around the time that I was
    > proposing to put together a standard block cipher module for Python.


    Ah, newsgroup messages. Anybody could respond, whether they have insight
    or not.

    >>The PSF does comply with the U.S. American export procedures for
    >>crypto code, and reports the crypto code in Python appropriately to BXA.

    >
    >
    > Since rotor was removed, there is no crypto code in Python that needs
    > reporting.


    We have released different versions of Python in the past. For Python
    2.2, a report about the rotor module was sent to BXA.

    Regards,
    Martin
    =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=, Jan 22, 2005
    #20
    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. Youhanna Mounir
    Replies:
    3
    Views:
    557
  2. Robin Becker

    rotor alternative?

    Robin Becker, Nov 18, 2003, in forum: Python
    Replies:
    60
    Views:
    1,533
    John J. Lee
    Nov 25, 2003
  3. Murphy Wong

    How to enable rotor in python 2.4.2?

    Murphy Wong, Jan 24, 2006, in forum: Python
    Replies:
    3
    Views:
    310
    Paul Rubin
    Jan 24, 2006
  4. Paul Rubin

    Missing rotor module

    Paul Rubin, Jul 25, 2006, in forum: Python
    Replies:
    5
    Views:
    324
    rony steelandt
    Jul 26, 2006
  5. Protoman

    Rotor class reverses wierdly

    Protoman, Dec 30, 2006, in forum: C++
    Replies:
    1
    Views:
    440
    Jim Langston
    Dec 30, 2006
Loading...

Share This Page