From bryan at EEVOLVED.COM Sun Dec 2 16:30:22 2001 From: bryan at EEVOLVED.COM (Bryan) Date: Sun, 2 Dec 2001 10:30:22 -0500 Subject: [PYTHON-CRYPTO] CryptKit 0.9 released Message-ID: This is a release notification for the CryptKit Project: http://eevolved.com/cryptkit/ CryptKit is a developer's toolkit implementing several of the most modern and efficient cryptographic algorithms. The kit is primarily written in ANSI C for speed and subsequently wrapped with SWIG for ease of use in python. The goal of this kit is twofold: - Efficiency and size. The kit is considerate of developer constraints on size and speed of applications. That is why CryptKit implements only the most efficient algorithms ( AES, ECC, DH, NR ) while maintaining small library size ( around 100KB compared to 2.1 MB for openSSL 0.9.6 ). - Ease of use. The kit aims to free programmers from having to understand the underlying cryptographic concepts that guarantee security. Instead, the structure is organized in a modular fashion, with wrapper classes that provide all the functionality. Ample documentation provides examples of class usage. CryptKit implements the following algorithms: Rijndael (AES), SHA 256 bits, Elliptic Curve PKI, Diffie-Hellman key exchange and Nyberg-Ruppel signature/verification. These modules are combined to provide a faster, lighter and easier to use secure socket alternative to SSL. CryptKit is not compatible with SSL. Whereas SSL aims to support a wide variety of algorithms that essentially perform the same task ( like DES/RC4/RC2 or MD5/SHA ), CryptKit takes the minimalist approach of implementing only one version of each crypto primitve. Great care went into selecting the best of what was available. I am currently examining Authenticated Key Exchange Schemes and am intending to implement AMP ( http://citeseer.nj.nec.com/kwon00authentication.html ). Any input is appreciated. -- <==================================> Bryan Mongeau eEvolved Real-Time Technologies Inc. Website: http://www.eevolved.com Public key: http://pgp.mit.edu <==================================> "The only real valuable thing is intuition."-- Einstein From strombrg at NIS.ACS.UCI.EDU Thu Dec 6 18:50:29 2001 From: strombrg at NIS.ACS.UCI.EDU (Dan Stromberg) Date: Thu, 6 Dec 2001 09:50:29 -0800 Subject: [PYTHON-CRYPTO] purpose of list Message-ID: <20011206095029.Q1548@seki.acs.uci.edu> Is this list for discussion of python cryptography in general, or "just" one particular crypto module for python? -- Dan Stromberg UCI/NACS/DCS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From strombrg at NIS.ACS.UCI.EDU Thu Dec 6 20:34:57 2001 From: strombrg at NIS.ACS.UCI.EDU (Dan Stromberg) Date: Thu, 6 Dec 2001 11:34:57 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: <20011206095029.Q1548@seki.acs.uci.edu>; from strombrg@nis.acs.uci.edu on Thu, Dec 06, 2001 at 09:50:29AM -0800 References: <20011206095029.Q1548@seki.acs.uci.edu> Message-ID: <20011206113457.Y1548@seki.acs.uci.edu> On Thu, Dec 06, 2001 at 09:50:29AM -0800, Dan Stromberg wrote: > Is this list for discussion of python cryptography in general, or "just" > one particular crypto module for python? > > -- > Dan Stromberg UCI/NACS/DCS I received an off-list reply indicating this was an ok forum for whatever python crypto. I recently sent this to comp.lang.python: ---------------------------------------------------------------------- I've placed a Diffie-Helman module in pure python at ftp://autoinst.acs.uci.edu/pub/python/dh . Comments on how to improve it are desired. I am NOT a cryptographer, so it may be worse than useless. Also included is a buffered socket implementation to prevent uncommon-but-possible short reads from being a problem in your code. Comments on this too are desired. A coworker has written an ssh wrapper module. Is anyone interested in seeing it? I could dig up permission from him to release it I think, and I'd personally kind of like seeing it get some peer review. ---------------------------------------------------------------------- I'll add that I've put a seed.py module at ftp://autoinst.acs.uci.edu/pub/python/seed. It tries to get a decent seed for a RNG first from /dev/random, than from /dev/urandom, then from prngd, then finally falling back on the time+pid if all else has failed. The D-H module does not yet use this seed.py module, so the seeding is not good in the D-H module yet. We use seed.py in production, but not the D-H module. -- Dan Stromberg UCI/NACS/DCS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From strombrg at NIS.ACS.UCI.EDU Thu Dec 6 20:57:27 2001 From: strombrg at NIS.ACS.UCI.EDU (Dan Stromberg) Date: Thu, 6 Dec 2001 11:57:27 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: ; from plambert@sprintmail.com on Thu, Dec 06, 2001 at 11:42:34AM -0800 References: <20011206095029.Q1548@seki.acs.uci.edu> <20011206113457.Y1548@seki.acs.uci.edu> Message-ID: <20011206115727.A1548@seki.acs.uci.edu> On Thu, Dec 06, 2001 at 11:42:34AM -0800, plambert at sprintmail.com wrote: > ...and have started working on some pure > python crypto libraries. They are intended to be written for > readability versus optimization. It's also nice not having to compile some C code to get your program working on a new system. Pure python's great for avoiding that. -- Dan Stromberg UCI/NACS/DCS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From Paul at CRYPTORIGHTS.ORG Thu Dec 6 21:37:19 2001 From: Paul at CRYPTORIGHTS.ORG (Paul) Date: Thu, 6 Dec 2001 12:37:19 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: <20011206115727.A1548@seki.acs.uci.edu> References: <20011206095029.Q1548@seki.acs.uci.edu> <20011206113457.Y1548@seki.acs.uci.edu> <20011206115727.A1548@seki.acs.uci.edu> Message-ID: At 11:57 AM -0800 12/6/01, Dan Stromberg wrote: >Attachment converted: Macintosh HD:Re- purpose of list 1 (MiME/CSOm) >(000346C2) > >*** PGP Signature Status: not verified (signing key missing) >*** Signer: 0x6D347FFF >*** Signed: N/A at N/A >*** Verified: 12/6/01 at 12:22 PM > >On Thu, Dec 06, 2001 at 11:42:34AM -0800, plambert at sprintmail.com wrote: >> ...and have started working on some pure >> python crypto libraries. They are intended to be written for >> readability versus optimization. > >It's also nice not having to compile some C code to get your program >working on a new system. Pure python's great for avoiding that. Yes ... I'm also over designing the interface to make it easy to use. Most cryptography is block oriented and some additional work is usually required to force the data into even increments of the block size. The padding algorithm is an important part of the processing that should be built into the api and algorithm. This should all be hidden from the usage of the algorithm and should be part of the Block class. For the readability ... I'm overloading basic operators (+, -, etc.) to work on finite fields of a variety of types. The original goal was to make an easy to read ECC implementation. I've attached an example of RC6 using overloading ... the encrypt and decrypt were written to correspond as closely as possible to the origninal RC6 specification. It is about 98% the same using overloading. Paul ----------------- # # crypto/cipher/rc6.py # # # Paul A. Lambert # # 991015 First Version ################################################## from crypto.cipher.base import Cipher from fmath.zed import Zn #----------------------------------------------------------------- class RC6(Cipher): def cipher_init( self, (w=32,r=20,b=16) ): self.name = 'RC6_CBE' self.strength = b * 8 self.key_size = b * 8 # b bytes of key self.block_size = w * 4 self.word_type = Zn(2L**w) # w bit Integer modular math self.words = 4 # 4 words of w bits each #-- RC6 Specific self.rounds = r self.P = { 16 : 0xB7E1, 32 : 0xB7E15163L, 128 : 0x73BDA93C2F3C92E5L } self.Q = { 16 : 0x9E377, 32 : 0x9E3779B9L, 128 : 0xE1D68B9C74BAD142L } S[0] = 0l A, B, i, j = 0 class RC6(cipher): __init__( self, w = 32, r = 20 , b = 16 ) self.w = w # word size in bits assert w = 32 # support only for 32 bit (need P and Q) self.block_size = w/8 # in bytes self.block_size = # in bytes self.word_size = None self.chunks = None self.chunk_type = 'Z2n' self.key_size = self.group = Zn(2L**w) self.S = key_expansion(L) def encrypt_block( self, (a,b,c,d) ): A, B, C, D = a, b, c, d lgw = self.word_type.lgw B = B + S[0] D = D + S[1] for i in interval(1,r): # for i = 1 to rounds t = ( B * ( 2*B + 1 )) << lgw u = ( D * ( 2*D + 1 )) << lgw A = (( A ^ t ) << u ) + S[2*i] C = (( C ^ u ) << t ) + S[2*i+1] A, B, C, D = B, C, D, A A = A + S[2*r+2] C = C + S[2*r+3] return( A, B, C, D ) def decrypt( A, B, C, D ): C = C - S[2*r+3] A = A - S[2*r+2] for i in interval(1,r): # for i = 1 to rounds A, B, C, D = D, A, B, C u = ( D * ( 2*D + 1 )) << lgw t = ( B * ( 2*B + 1 )) << lgw C = (( C - S[2*i+1] ) >> t ) ^ u A = (( A - S[2*i] ) >> u ) ^ t D = D - S[1] B = B - S[0] return( A, B, C, D ) def key_expansion( key_bytes, r ): """The RC6 key expansion uses the input octet array L to create the key schedule array S. """ L = self.word_type.fromBytes( key_bytes[:] ) c = len(L) S[0] = 0xB7E15163L for i in interval( 1, 2*r+3 ): S[ i ] = S[ i-1 ] + 0x9E3779B9L A = B = i = j = Z2m( w, 0L ) # assign to zero v = 3 * max( c, 2*r + 4 ) for s in interval( 1, v ): A = S[ i ] = ( S[ i ] + A + B ) << 3 B = L[ j ] = ( L[ j ] + A + B ) << ( A + B ) i = ( i + 1 ) % ( 2*r + 1 ) j = ( j + 1 ) % c return S -- From Paul at CRYPTORIGHTS.ORG Thu Dec 6 21:40:07 2001 From: Paul at CRYPTORIGHTS.ORG (Paul) Date: Thu, 6 Dec 2001 12:40:07 -0800 Subject: [PYTHON-CRYPTO] Fwd: Rejected posting to PYTHON-CRYPTO@NIC.SURFNET.NL Message-ID: > >On Thu, Dec 06, 2001 at 09:50:29AM -0800, Dan Stromberg wrote: >>> Is this list for discussion of python cryptography in general, or "just" >>> one particular crypto module for python? >>> >>> -- >>> Dan Stromberg UCI/NACS/DCS >> >>I received an off-list reply indicating this was an ok forum for >>whatever python crypto. >> > >Glad to see some activity on the list. I've just recently starting >lurking here. I'm interested, and have started working on some pure >python crypto libraries. They are intended to be written for >readability versus optimization. I've got a couple modules done and >will publish soon ... this month I'm working on key splitting. > >Will post here when they are done ... also will be working on the >BDANGEROUS (pun on BSAFE) list on source forge. > >Paul A. Lambert > -- From bram at GAWTH.COM Fri Dec 7 05:56:13 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Thu, 6 Dec 2001 20:56:13 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: <20011206113457.Y1548@seki.acs.uci.edu> Message-ID: On Thu, 6 Dec 2001, Dan Stromberg wrote: > I've placed a Diffie-Helman module in pure python at > ftp://autoinst.acs.uci.edu/pub/python/dh . A few comments - Are you aware that the built-in pow() function takes an optional third argument which is the modulus? That seems to eliminate the need for your powmod module. The 'standard' moduli to use are listed here - http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-01.txt The built-in whrandom and random modules aren't even vaguely cryptographically secure, you should use a cryptographically secure PRNG. Your conversion.py is very inefficient. It can be made more efficient by using some built-in modules in a somewhat hacky manner, here's the code (copied from the BitTorrent source) - # Written by Bram Cohen # This file is public domain # The authors disclaim all liability for any damages resulting from # any use of this software. from binascii import b2a_hex, a2b_hex def int_to_binary(numin, size): x = hex(numin)[2:] if x[-1] == 'L': x = x[:-1] if len(x) % 2 == 1: x = '0' + x x = a2b_hex(x) x = ('\000' * (size - len(x))) + x return x def binary_to_int(s): return long(b2a_hex(s), 16) There's no need to set q to be some funny prime, if you use one of the standard moduli 2 is perfectly acceptable. Also, any wire protocol will necessarily have it's own quirks, and the particular API each one exposes varies widely, so the chances of someone wanting to use your particular API for doing diffie-hellman are pretty small. If you'd like to see Diffie-Hellman in use in complete application, I suggest you check out my project, BitTorrent, which you can find here - http://bitconjurer.org/BitTorrent/ -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at GAWTH.COM Fri Dec 7 06:03:57 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Thu, 6 Dec 2001 21:03:57 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: Message-ID: On Thu, 6 Dec 2001, Paul wrote: > For the readability ... I'm overloading basic operators (+, -, etc.) > to work on finite fields of a variety of types. The original goal > was to make an easy to read ECC implementation. I take it you're using + for the ECC group operation, rather than *. A reasonable argument can be made for making it *, because when people stare at lots of code using + they naturally think there's a corresponding *, which in the case of ECC there isn't. Are you also going to overload multiplication by scalars? That's another example of where multiplication as the group operator is clearer - 3 * x and x * 3 look like they should be the same thing, although 3 * x is confusing when you're not in a field, while x ** 3 is quiet understandable. > assert w = 32 # support only for 32 bit (need P and Q) shouldn't that be assert w == 32 ? Here's a pure python implementation of AES - be forewarned it's very, very slow. http://bitconjurer.org/rijndael.py -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From Paul at CRYPTORIGHTS.ORG Fri Dec 7 07:14:11 2001 From: Paul at CRYPTORIGHTS.ORG (Paul) Date: Thu, 6 Dec 2001 22:14:11 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: References: Message-ID: At 9:03 PM -0800 12/6/01, Bram Cohen wrote: >On Thu, 6 Dec 2001, Paul wrote: > >> For the readability ... I'm overloading basic operators (+, -, etc.) >> to work on finite fields of a variety of types. The original goal >> was to make an easy to read ECC implementation. > >I take it you're using + for the ECC group operation, rather than *. I'm just getting restarted on the code after having it on the shelf for a year plus. I have not started the ECC et, but was working on other base classes. I plan to simply take the existing specifications and write code as close as possible to the standards. The idea was originally to see if I could make something that read as a specification, but was able to run as code. Lots of slow magic happens behind the curtain ... in this case by the operator overloading. So I think the answer is "*" for IEEE 1363. The Block class is also a little odd with this philosophy. The Blocks need to be of the field type used by the algorithm. I'll post a full example ... hopefully late next week if time permits. >A >reasonable argument can be made for making it *, because when people stare >at lots of code using + they naturally think there's a corresponding *, >which in the case of ECC there isn't. Are you also going to overload >multiplication by scalars? Again ... I'm going to make the code match the specification as closely as possible, SO it depends on the base specification. I plan to use IEEE 1363 for ECC. > >Here's a pure python implementation of AES - be forewarned it's very, very >slow. > >http://bitconjurer.org/rijndael.py Way cool ... thanks!! Paul > >-Bram Cohen > >"Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes -- From Eric.Johnson at GDAI.COM Fri Dec 7 16:10:57 2001 From: Eric.Johnson at GDAI.COM (Eric Johnson) Date: Fri, 7 Dec 2001 10:10:57 -0500 Subject: [PYTHON-CRYPTO] purpose of list Message-ID: >> For the readability ... I'm overloading basic operators (+, -, etc.) >> to work on finite fields of a variety of types. The original goal >> was to make an easy to read ECC implementation. > >I take it you're using + for the ECC group operation, rather than *. A >reasonable argument can be made for making it *, because when people stare >at lots of code using + they naturally think there's a corresponding *, >which in the case of ECC there isn't. Are you also going to overload >multiplication by scalars? That's another example of where multiplication >as the group operator is clearer - 3 * x and x * 3 look like they should >be the same thing, although 3 * x is confusing when you're not in a field, >while x ** 3 is quiet understandable. Conventionally mathematicians use + for Abelian groups and * for non-Abelian groups. So I think a mathematician would expect 3 + x = x + 3 but 3 * x != x * 3 I think the only benefit in using multiplicative notation is that you can make DH and the like look more like the discrete log case and so aid understanding. I used to think that overloading operators was a good thing and once did C++ code that could do a Euclidean gcd algorithm on polynomials with overloaded + and * operators. However, I know think it is a terrible thing and leads to more confusion and a loss of clarity. It is very tempting to write x ** 3 to when x is a point on the curve but we're going to have x1 ** 3 in other places where x1 is an integer and we can never be quite sure of the semantics of the operators whereas a method name can be better. The other problem one encounters is how to overload * when working in both Zq* and Zp* -- just which field are we using? In ECC systems with more than one curve which one is associated with the * operator? Please, please don't do it. Eric From LISTSERV at NIC.SURFNET.NL Fri Dec 7 19:43:15 2001 From: LISTSERV at NIC.SURFNET.NL (L-Soft list server at SURFnet (The Netherlands) (1.8d)) Date: Fri, 7 Dec 2001 19:43:15 +0100 Subject: PYTHON-CRYPTO: zooko@ZOOKO.COM joined the list Message-ID: <200112071843.TAA06919@post.webmailer.de> Fri, 7 Dec 2001 19:43:15 Zooko O'Whielacronx has just subscribed to the PYTHON-CRYPTO list (generic crypto class API for Python). From bram at GAWTH.COM Fri Dec 7 21:04:10 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Fri, 7 Dec 2001 12:04:10 -0800 Subject: [PYTHON-CRYPTO] purpose of list In-Reply-To: Message-ID: On Fri, 7 Dec 2001, Eric Johnson wrote: > Conventionally mathematicians use + for Abelian groups and * for > non-Abelian > groups. So I think a mathematician would expect > 3 + x = x + 3 > but > 3 * x != x * 3 Dan Bonez, a mathematician who's done some important work in crypto, showed me an example in which he used * for the group operation in ECC, so it has at least some use. > I used to think that overloading operators was a good thing and once > did C++ code that could do a Euclidean gcd algorithm on polynomials > with overloaded + and * operators. > > However, I know think it is a terrible thing and leads to more > confusion and a loss of clarity. It is very tempting to write x ** 3 > to when x is a point on the curve but we're going to have x1 ** 3 in > other places where x1 is an integer and we can never be quite sure of > the semantics of the operators whereas a method name can be better. > The other problem one encounters is how to overload * when working in > both Zq* and Zp* -- just which field are we using? In ECC systems with > more than one curve which one is associated with the * operator? Yes, the received wisdom is to generally not use operator overloading, and it's true that you can shoot yourself in the foot with it incredibly easily, although once in a great while it does increase redability. For example, I once wrote a VersionNumber class which implemented standard a.b.c style versioning and implemented __cmp__, __str__ and __repr__ methods, which worked pretty well. Although, that was the only case where I used overloading in python, and it could have worked just fine as a bunch of functions. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From andy at DUSTMAN.NET Thu Dec 13 23:38:45 2001 From: andy at DUSTMAN.NET (Andy Dustman) Date: Thu, 13 Dec 2001 17:38:45 -0500 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) Message-ID: <1008283125.7240.12.camel@chef.comstar.net> Here's a sticky bit for PEP-272: There is at least one cipher out there (IDEA) which uses a different key schedule for decryption than it does for encryption. If new() sets up the key schedule, then it will need a keyword argument (decrypt=1) so it can know how to build the key schedule. But then, both encrypt() and decrypt() cannot work on the same instance; only the method for which the key schedule is set up for will work properly, and the other will return undefined trash. OTOH, it may be worthwhile, in cases like these, to retain the knowledge of which key schedule was created, and if the wrong method is called, raise an exception. As an alternative, the key schedule set up could be delayed until the first encrypt() or decrypt(), which means storing the key in the cipher instance and recognizing that key set up has not been done on the first method call. Should we have a general API rule that only encrypt() or decrypt() may be called on a cipher instance, and if the other is called then a) you get an exception or b) undefined results? Any preferences? -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From mal at LEMBURG.COM Fri Dec 14 00:08:19 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Fri, 14 Dec 2001 00:08:19 +0100 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) References: <1008283125.7240.12.camel@chef.comstar.net> Message-ID: <3C1934E3.D249453F@lemburg.com> Andy Dustman wrote: > > Here's a sticky bit for PEP-272: There is at least one cipher out there > (IDEA) which uses a different key schedule for decryption than it does > for encryption. > > If new() sets up the key schedule, then it will need a keyword argument > (decrypt=1) so it can know how to build the key schedule. But then, both > encrypt() and decrypt() cannot work on the same instance; only the > method for which the key schedule is set up for will work properly, and > the other will return undefined trash. OTOH, it may be worthwhile, in > cases like these, to retain the knowledge of which key schedule was > created, and if the wrong method is called, raise an exception. > > As an alternative, the key schedule set up could be delayed until the > first encrypt() or decrypt(), which means storing the key in the cipher > instance and recognizing that key set up has not been done on the first > method call. > > Should we have a general API rule that only encrypt() or decrypt() may > be called on a cipher instance, and if the other is called then a) you > get an exception or b) undefined results? I'd say b) since this depends on the cipher in question, i.e. some ciphers may allow mixing the two while other give undefined results. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From akuchlin at MEMS-EXCHANGE.ORG Fri Dec 14 06:16:17 2001 From: akuchlin at MEMS-EXCHANGE.ORG (A.M. Kuchling) Date: Fri, 14 Dec 2001 00:16:17 -0500 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: <1008283125.7240.12.camel@chef.comstar.net>; from andy@DUSTMAN.NET on Thu, Dec 13, 2001 at 05:38:45PM -0500 References: <1008283125.7240.12.camel@chef.comstar.net> Message-ID: <20011214001617.A15811@mozart.mems-exchange.org> On Thu, Dec 13, 2001 at 05:38:45PM -0500, Andy Dustman wrote: >If new() sets up the key schedule, then it will need a keyword argument >(decrypt=1) so it can know how to build the key schedule. But then, both Why not build them both? I think that's what the pycrypt code does; the key schedules aren't that large and you probably don't have hundreds of thousands of encryption objects, so the extra memory and processing time is negligible. --amk (www.amk.ca) I don't think we should use rational numbers for money because money isn't rational. -- Moshe Zadka, at IPC9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From phr-pycrypt at nightsong.com Fri Dec 14 06:21:21 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Fri, 14 Dec 2001 05:21:21 -0000 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) Message-ID: <20011214052121.16537.qmail@brouhaha.com> >If new() sets up the key schedule, then it will need a keyword argument >(decrypt=1) so it can know how to build the key schedule. But then, both Why not build them both? I think that's what the pycrypt code does; the key schedules aren't that large and you probably don't have hundreds of thousands of encryption objects, so the extra memory and processing time is negligible. How about an argument that says what operation(s) should be supported: new(op='d') # encrypt only new(op='e') # encrypt only new(op='de') # both Other operations can be supported: new(op='s') # sign digital signature or message authentication code new(op='v') # verify signature from above and so forth. This is similar to a package I've been working on. Is a draft copy of PEP 272 actually available somewhere? From alex at BOFH.TORUN.PL Fri Dec 14 13:14:06 2001 From: alex at BOFH.TORUN.PL (Janusz A. Urbanowicz) Date: Fri, 14 Dec 2001 13:14:06 +0100 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: <1008283125.7240.12.camel@chef.comstar.net> from Andy Dustman at "Dec 13, 2001 05:38:45 pm" Message-ID: Andy Dustman wrote/napisa?[a]/schrieb: > Should we have a general API rule that only encrypt() or decrypt() may > be called on a cipher instance, and if the other is called then a) you > get an exception or b) undefined results? I have though on this issue and the result was as following: any given copher is a subclass of class Cipher which has three public methods - the constructor, encrypt() and decrypt(). The key is supplied to __init__() when instantiating the class and you later use the object to enrypt with the key. Seemed pretty straightforward to me. Alex -- C _-=-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | * ; (_O : +-------------------------------------------------------------+ --+~| ! &~) ? | P?yn?? chc? na Wsch?d, za Suez, gdzie jest dobrem ka?de z?o | l_|/ A ~-=-~ O| Gdzie przykaza? brak dziesi?ciu, a pi? mo?na a? po dno; | | From andy at DUSTMAN.NET Fri Dec 14 16:42:02 2001 From: andy at DUSTMAN.NET (Andy Dustman) Date: Fri, 14 Dec 2001 10:42:02 -0500 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: References: Message-ID: <1008344522.10256.9.camel@chef.comstar.net> BTW, I think the list setting Reply-To: to go back to the original sender is obnoxious. It may actually be more obnoxious than setting Reply-To: to go to the list. On Fri, 2001-12-14 at 07:14, Janusz A. Urbanowicz wrote: > Andy Dustman wrote/napisa?[a]/schrieb: > > Should we have a general API rule that only encrypt() or decrypt() may > > be called on a cipher instance, and if the other is called then a) you > > get an exception or b) undefined results? > > I have though on this issue and the result was as following: any given > copher is a subclass of class Cipher which has three public methods - the > constructor, encrypt() and decrypt(). The key is supplied to __init__() when > instantiating the class and you later use the object to enrypt with the > key. Seemed pretty straightforward to me. It is, for most ciphers. But not for IDEA: The key schedule has to be initialized differently depending on whether or not you want to encrypt or decrypt. I think amk's solution of computing both key schedules would be okay, except that I seem to remember that IDEA's decryption key schedule takes a lot longer to compute than for encryption. Also, for any cipher mode which maintains an IV, encrypt() and decrypt() really will be mutually-exclusive for a given instance. ECB is the only supported mode that doesn't use an IV. (BTW, the PGP mode needs an IV as well, but the PEP doesn't reflect this.) -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From alex at BOFH.TORUN.PL Fri Dec 14 16:43:12 2001 From: alex at BOFH.TORUN.PL (Janusz A. Urbanowicz) Date: Fri, 14 Dec 2001 16:43:12 +0100 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: <1008344522.10256.9.camel@chef.comstar.net> from Andy Dustman at "Dec 14, 2001 10:42:02 am" Message-ID: Andy Dustman wrote/napisa?[a]/schrieb: [Charset iso-8859-13 unsupported, skipping...] (what a weird charset..) > It is, for most ciphers. But not for IDEA: The key schedule has to be > initialized differently depending on whether or not you want to encrypt > or decrypt. So during __init__ I'd calculate both to be used when needed. Alex -- C _-=-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | * ; (_O : +-------------------------------------------------------------+ --+~| ! &~) ? | P?yn?? chc? na Wsch?d, za Suez, gdzie jest dobrem ka?de z?o | l_|/ A ~-=-~ O| Gdzie przykaza? brak dziesi?ciu, a pi? mo?na a? po dno; | | From michael at STROEDER.COM Fri Dec 14 17:17:09 2001 From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 14 Dec 2001 17:17:09 +0100 Subject: [PYTHON-CRYPTO] Meta: Reply-To setting of this list (was PEP-272 ..) References: <1008344522.10256.9.camel@chef.comstar.net> Message-ID: <3C1A2605.9936A27E@stroeder.com> Andy Dustman wrote: > > BTW, I think the list setting Reply-To: to go back to the original > sender is obnoxious. It may actually be more obnoxious than setting > Reply-To: to go to the list. FYI: I switched off Reply-To -> PYTHON-CRYPTO at NIC.SURFNET.NL intentionally because there were some replies going to the list obviously dedicated only to the sender of a posting. Also mailing lists tend to be more vulnerable for mail loops caused by vacation mailers if a Reply-To: is set to the list. Most MUAs have a quick button for "Reply To All" which should do the trick. And editing the To: and Cc: lines should not overstrain the capabilities of the folks here. Ciao, Michael. From andy at DUSTMAN.NET Fri Dec 14 17:29:47 2001 From: andy at DUSTMAN.NET (Andy Dustman) Date: Fri, 14 Dec 2001 11:29:47 -0500 Subject: [PYTHON-CRYPTO] Meta: Reply-To setting of this list (was PEP-272 ..) In-Reply-To: <3C1A255A.3F7783FF@stroeder.com> References: <1008344522.10256.9.camel@chef.comstar.net> <3C1A255A.3F7783FF@stroeder.com> Message-ID: <1008347387.10256.12.camel@chef.comstar.net> On Fri, 2001-12-14 at 11:14, Michael Str?der wrote: > Andy Dustman wrote: > > > > BTW, I think the list setting Reply-To: to go back to the original > > sender is obnoxious. It may actually be more obnoxious than setting > > Reply-To: to go to the list. > > FYI: > I switched off Reply-To: PYTHON-CRYPTO at NIC.SURFNET.NL intentionally > because there were some replies going to the list obviously > dedicated only to the sender of a posting. Also mailing lists tend > to be more vulnerable for mail loops caused by vacation mailers if a > Reply-To: is set to the list. You missed the point: Having the list set Reply-To:, whether to the original sender or to the list, is a nuisance. The solution for vacation mailers is to kick them off the list with extreme prejudice. > Most MUAs have a quick button for "Reply To All" which should do the > trick. And editing the To: and Cc: lines should not overstrain the > capabilities of the folks here. Then why set Reply-To: at all? Just "Reply To All" and remove the recipients you don't want to send to (either the list or the sender). -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From andy at DUSTMAN.NET Fri Dec 14 17:36:25 2001 From: andy at DUSTMAN.NET (Andy Dustman) Date: Fri, 14 Dec 2001 11:36:25 -0500 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: <20011214001617.A15811@mozart.mems-exchange.org> References: <1008283125.7240.12.camel@chef.comstar.net> <20011214001617.A15811@mozart.mems-exchange.org> Message-ID: <1008347786.10256.14.camel@chef.comstar.net> On Fri, 2001-12-14 at 00:16, A.M. Kuchling wrote: > On Thu, Dec 13, 2001 at 05:38:45PM -0500, Andy Dustman wrote: > >If new() sets up the key schedule, then it will need a keyword argument > >(decrypt=1) so it can know how to build the key schedule. But then, both > > Why not build them both? I think that's what the pycrypt code does; > the key schedules aren't that large and you probably don't have > hundreds of thousands of encryption objects, so the extra memory and > processing time is negligible. Looking at the OpenSSL headers, you have to build the encryption key schedule before you can build the decryption key schedule, so you have to build both anyway to decrypt. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From jason-list-python-crypto at MASTALER.COM Sat Dec 15 23:54:02 2001 From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler) Date: Sat, 15 Dec 2001 15:54:02 -0700 Subject: [PYTHON-CRYPTO] PEP-272 (API for Secret-Key Encryption Algorithms) In-Reply-To: <20011214052121.16537.qmail@brouhaha.com> (phr-pycrypt@nightsong.com's message of "14 Dec 2001 05:21:21 -0000") References: <20011214052121.16537.qmail@brouhaha.com> Message-ID: phr-pycrypt at nightsong.com writes: > Is a draft copy of PEP 272 actually available somewhere? http://python.sourceforge.net/peps/pep-0272.html -- (TMDA - http://tmda.sourceforge.net) (Python-based SPAM reduction system) From Paul at CRYPTORIGHTS.ORG Sun Dec 16 21:15:51 2001 From: Paul at CRYPTORIGHTS.ORG (Paul) Date: Sun, 16 Dec 2001 12:15:51 -0800 Subject: [PYTHON-CRYPTO] PEP-272 Deficiencies - Comments In-Reply-To: References: <20011214052121.16537.qmail@brouhaha.com> Message-ID: At 3:54 PM -0700 12/15/01, Jason R. Mastaler wrote: >phr-pycrypt at nightsong.com writes: > >> Is a draft copy of PEP 272 actually available somewhere? > >http://python.sourceforge.net/peps/pep-0272.html This api has several problems: 1) I agree with Janusz A. Urbanowicz's earlier note that symmetric encryption should be a class. The initialization can give it the key. Note that it may later need to be reinitialized, so a set_key(key) method should also be available and the initialization should be optional (but raise an exception on use when no key is available) 2) The modes of operation should not be parameters. The modes create new algorithms types. It's easy to spin out new mode algorithms with a mode "wrapper" class. 3) A class based implementation of an encryption algorithm should be able to handle large strings or files that may not all be in a single variable. Please consider the example of encrypting large multi-gigabyte files. So there are a couple of possible approaches: a) you need two or three methods for encryption to indicate when you have full data versus partial b) use you a parameter in encrypt to indicate if more data might be coming For example: ct = aes.encrypt('abcdefghijklmnop') versus ct = aes.encrypt_partial('abc') ct = ct + aes.encrypt('defghijklmnop') I've written all my algorithms for option "b" above, but the example and option "a" look like they read a little better. Note that above implementation requires that the algorithm class store non-byte aligned data between encryption steps. It also means that algorithm classes have a common perception of "state". Algorithm states might be: "unkeyed" - class existing, but key not set or not valid "ready" - good key no data has been processed "midstream" - some data encrypted, more possible must store alg state and excess non-aligned bytes. When the final a bit of data is processed this state goes back to "ready" and all local stuff (alg state, key tables) should be reset All of the above could be made easy for an api by creating a SymmetricCipher Class that all specific algorithms are derived from. 4) IV should not be a parameter, but should be built into the algorithms that require IVs. If you ever get around to using hardware based cryptography it is very important to have the IV generated by the hardware. This also ensures that a "good" IV generation method is built into the base algorithms. This also implies that 5) Naming conventions should be provided to allow for block oriented algorithms to automatically provide padding. This is a big hole in current algorithm standards work. In a year or so NIST may catch up. Similar to the way a mode (like CBC) augments a base cipher, a padding mode defines how a block aligned transformation can be extended to be byte aligned. Paul A. Lambert -- From alex at BOFH.TORUN.PL Sun Dec 16 22:12:32 2001 From: alex at BOFH.TORUN.PL (Janusz A. Urbanowicz) Date: Sun, 16 Dec 2001 22:12:32 +0100 Subject: [PYTHON-CRYPTO] PEP-272 Deficiencies - Comments In-Reply-To: from Paul at "Dec 16, 2001 12:15:51 pm" Message-ID: Paul wrote/napisa?[a]/schrieb: > At 3:54 PM -0700 12/15/01, Jason R. Mastaler wrote: > >phr-pycrypt at nightsong.com writes: > > > >> Is a draft copy of PEP 272 actually available somewhere? > > > >http://python.sourceforge.net/peps/pep-0272.html > > This api has several problems: > > 1) I agree with Janusz A. Urbanowicz's earlier note that symmetric > encryption should be a class. The initialization can give it the > key. Note that it may later need to be reinitialized, so a > set_key(key) method should also be available and the initialization > should be optional (but raise an exception on use when no > key is available) I don't like it very much. This breaks the OO design view - any instance of CIpher is a cipher with a particular key. If you want to change the key, yopu create a new instacne of the class. If there is absolutely a must of some set_key method, it should return a new instance of the class, not reset the live object. > 2) The modes of operation should not be parameters. The modes create > new algorithms types. It's easy to spin out new mode algorithms with > a mode "wrapper" class. Agreed. I thought of it that way: there are three base classes: Cipher for symmetric key, Encryptor for pubkey and Hash for hashes. Any given cipher algorithm is a subclass of Cipher etc. A variation of algorithm is a subclass of base cipher. So it would be that 3DES-CBC is a subclass of 3DES, which is a subclass of DES which is a subclass of Cipher. Alex -- C _-=-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | * ; (_O : +-------------------------------------------------------------+ --+~| ! &~) ? | P?yn?? chc? na Wsch?d, za Suez, gdzie jest dobrem ka?de z?o | l_|/ A ~-=-~ O| Gdzie przykaza? brak dziesi?ciu, a pi? mo?na a? po dno; | | From Paul at CRYPTORIGHTS.ORG Mon Dec 17 03:44:38 2001 From: Paul at CRYPTORIGHTS.ORG (Paul) Date: Sun, 16 Dec 2001 18:44:38 -0800 Subject: [PYTHON-CRYPTO] PEP-272 Deficiencies - Comments In-Reply-To: References: Message-ID: At 10:12 PM +0100 12/16/01, Janusz A. Urbanowicz wrote: >Paul wrote/napisa?[a]/schrieb: >> At 3:54 PM -0700 12/15/01, Jason R. Mastaler wrote: >> >phr-pycrypt at nightsong.com writes: >> > >> >> Is a draft copy of PEP 272 actually available somewhere? >> > >> >http://python.sourceforge.net/peps/pep-0272.html >> >> This api has several problems: >> >> 1) I agree with Janusz A. Urbanowicz's earlier note that symmetric >> encryption should be a class. The initialization can give it the >> key. Note that it may later need to be reinitialized, so a >> set_key(key) method should also be available and the initialization >> should be optional (but raise an exception on >>use when no >> key is available) > >I don't like it very much. This breaks the OO design view - any instance of >CIpher is a cipher with a particular key. If you want to change the key, >yopu create a new instacne of the class. Hum,,, generally I like the idea. There are times when a algorithm gets "rekeyed". Changing keys on an exisitng IPsec security association is an example. Seem like you could just assign a new instance. So .... good idea, I'll leave out set_key. > >If there is absolutely a must of some set_key method, it should return a new >instance of the class, not reset the live object. Ok. Better to have less methods ... I like your definition of that an instance is bound to a key. > >> 2) The modes of operation should not be parameters. The modes create >> new algorithms types. It's easy to spin out new mode algorithms with >> a mode "wrapper" class. > >Agreed. I thought of it that way: there are three base classes: Cipher for >symmetric key, Encryptor for pubkey and Hash for hashes. Any given cipher >algorithm is a subclass of Cipher etc. A variation of algorithm is a subclass >of base cipher. So it would be that 3DES-CBC is a subclass of 3DES, which is a >subclass of DES which is a subclass of Cipher. Public key can provide both encryption and signature functions. If you follow the instance bound to a key notion, then you need classes for public encryption, public decryption, public signature and public signature validation. Regards, Paul -- From alex at BOFH.TORUN.PL Mon Dec 17 14:21:16 2001 From: alex at BOFH.TORUN.PL (Janusz A. Urbanowicz) Date: Mon, 17 Dec 2001 14:21:16 +0100 Subject: [PYTHON-CRYPTO] PEP-272 Deficiencies - Comments (fwd) Message-ID: This was accidentally sent offlist. Regards. Alex -- C _-=-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | * ; (_O : +-------------------------------------------------------------+ --+~| ! &~) ? | P?yn?? chc? na Wsch?d, za Suez, gdzie jest dobrem ka?de z?o | l_|/ A ~-=-~ O| Gdzie przykaza? brak dziesi?ciu, a pi? mo?na a? po dno; | | -------------- next part -------------- An embedded message was scrubbed... From: Janusz A. Urbanowicz Subject: Re: [PYTHON-CRYPTO] PEP-272 Deficiencies - Comments Date: Mon, 17 Dec 2001 14:04:25 +0100 (CET) Size: 2487 URL: From andy at DUSTMAN.NET Mon Dec 17 19:18:49 2001 From: andy at DUSTMAN.NET (Andy Dustman) Date: Mon, 17 Dec 2001 13:18:49 -0500 Subject: [PYTHON-CRYPTO] [NIST SP 800-38A] Recommendation for Block Cipher Modes of Operation Message-ID: <1008613129.24464.14.camel@chef.comstar.net> I picked this up on Bruce Schneier's Crypto-Gram. There are a few modes not covered by PEP-272 that would probably be good to add as supported modes, even if some of them aren't widely supported in practice yet. NIST special publication SP 800-38A, "Recommendation for Block Cipher Modes of Operation," is also available. The initial modes are ECB, CBC, CFB, OFB, and CTR. Other modes will be added at a later time. SP 800-38A: http://www.counterpane.com/crypto-gram-0112.html Incidentally, PEP-272 should probably make mention that CFB and OFB typically have a variable segment size, and that sometimes this will be limited by the implementation. For example, the NIST document above specifies CFB-1, -8, and -128 for AES; but OpenSSL's IDEA implementation only includes CFB-64. Which raises the question: Should the segment size be a keyword parameter to new(), i.e. AES.new(AES.CFB, key, IV, segment=128); or should it be incorporated into the mode, i.e. AES.new(AES.CFB128, key, IV)? If the latter, it calls into question the feedback modes table in PEP-272. Perhaps feedback modes should be an opaque (implementation-dependent) data type, using standardized naming. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: