From z3p at TWISTEDMATRIX.COM Fri Jul 19 01:44:14 2002 From: z3p at TWISTEDMATRIX.COM (Paul Swartz) Date: Thu, 18 Jul 2002 19:44:14 -0400 Subject: [PYTHON-CRYPTO] Twisted.Conch, an SSH module for Twisted Message-ID: <3D371A8E.8734.8DE0CD@localhost> I felt that some people on this list might want to look at this, so I'm making an annoucement here. I am working on an implementation of the SSH2 protocol for Python using the Twisted asychronous networking library (http://www.twistedmatrix.com/). It supports most types of public and private key encryption thanks to the Python Cryptography library. Currently, the server is further along, but both server and client support authentication. Some unit tests are available, to the test the key handling, and the server and client against each other. The code is available in Twisted CVS, and instructions for checking out a copy are on the Twisted website. -p -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p at twistedmatrix.com V_/_ AIM: Z3Penguin From clee at spiralis.merseine.nu Thu Jul 18 22:13:43 2002 From: clee at spiralis.merseine.nu (Chris Lee) Date: Thu, 18 Jul 2002 15:13:43 -0500 Subject: [PYTHON-CRYPTO] PGP/MIME vs S/MIME questions Message-ID: <15671.8567.551014.138368@spiralis.merseine.nu> Hello, I'm a crypto newbie and I'm writing an application that needs to send and archive signed and/or encrypted mail. I've been looking over the RFCs for S/MIME and PGP/MIME subtypes. I've only have experience sending and received messages using the pgp standard, and I'm unsure as to what the advantages/disadvantages are of the two formats. What I have guessed so far based upon my rather incomplete review of the available data: - The pgp-based mime message types are the most used currently. But S/MIME is used in many commercial applications??? - pgp-based mime currently relies upon calling either pgp or gpg (I haven't found free, in-process libraries to do the job) - S/MIME looks more complicated - S/MIME might be the standard for the future ??? Seeing that M2Crypto has a HOWTO for generating S/MIME messages, I was hoping that there might be active developers using S/MIME or the PGP/MIME-subtypes who might share their wisdom on how to decide which to use. Thanks in advance, -chris ------------------------------------- References: Status of two protocols http://www.imc.org/smime-pgpmime.html Includes table comparing algorithms for both protocols (and see http://www.imc.org for RFCs) PGP/MIME: [1] RFCs 1847 and 2015 S/MIME: [2] http://www.rsasecurity.com/standards/smime/faq.html [3] RFCs 2630,2633,2632,2631 format, handling certificates, CMS, etc. From phr-pycrypt at nightsong.com Thu Jul 25 07:19:04 2002 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Thu, 25 Jul 2002 05:19:04 -0000 Subject: [PYTHON-CRYPTO] Persistent keylist with secure deletion Message-ID: <20020725051904.4902.qmail@brouhaha.com> Note: This is a copy of a sci.crypt post. Python code to implement the below is at: http://www.nightsong.com/phr/crypto/keytree.py Suppose you want to store N encrypted files, numbered 0, ..., N-1. You want to be able to access any or all of them with a single passphrase. You also want to be able to delete any file securely, so it can't be recovered. However, all the sci.crypt posts about secure deletion have convinced you that once you write something to a disk drive, it can never be erased: for example, it can be recovered with fancy magnetometers, or maybe the drive itself might decide to relocate sectors from the file from one place to another without telling you. OK, you encrypt each file with its own random key, K0,...,K_(N-1), and encrypt each key with the passphrase. Then if you can securely delete a key, the file can't be recovered. But now storing the keys to disk has the same problem as storing the files to disk. If analyzing the disk reveals every state it's ever been in, and there's no other persistent data store in your computer, there's no solution. Of course you've set up your system so that RAM contents are never paged to disk, so you can hold secret keys in system RAM, but that's only for temporary operations since a system crash wipes out the regular RAM. But there are other places to squirrel away data. PC's have a few dozen bytes of CMOS memory (usually 32 or 64 bytes) which hold stuff like the real-time clock (10 bytes) and the HD parameters (sometimes not needed any more). Or devices like the Dallas DS1991 and DS1992 iButtons, http://www.ibutton.com/ibuttons/memory.html connect to the computer's serial port and hold some data (1-64 kbits) in internal NVRAM. The DS1992 even has a password protection feature, so it can become an authentication token as well as a key store. Unlike the Java iButton, though, they aren't crypto devices and don't have fancy firmware. So you can buy them without dealing with export restrictions or obnoxious vendor licenses. Also, they're much cheaper than the Java iButton. But what about those N keys, that won't fit in the NVRAM? Suppose you can fit just one key in NVRAM. That turns out to be enough--here's a simple but workable approach: Generate a random key R and store it in NVRAM. Use R to encrypt your list of N keys and write the encrypted list to disk. To delete a key K_i, read R from the NVRAM, then generate a new random key R' and store that in NVRAM, overwriting R. Use the old R to decrypt the list, and use R' to write a new encrypted list omitting K_i (write random data in K_i's slot). Since R is permanently gone, the file can't be read. The trouble with the above scheme is that if you have N slots, it takes O(N) operations to read and write the file. So that's slow if N is large. The solution is to use a tree structure: store a "root key" in NVRAM. Use it to encrypt a key on disk. Use that key to encrypt two more keys, and each of those to encrypt two more keys, etc. The keys are in a binary tree where each node has an encryption key E and a user key V. V is encrypted by E, E is encrypted by the node's parent's E, and so on up to the root. To delete a V, you simply change the E for that node, and its parent, etc. You have to remember to re-encrypt the node's sibling's V, and the node's children's V's if the node has any children. Still this is a total of O(log N) operations, which is ok for reasonable values of N. A sample implementation in Python is at: http://www.nightsong.com/phr/crypto/keytree.py which also includes an AES-like block cipher (128 bit blocks) written in Python (actually just a Luby-Rackoff construction using SHA as the round function). It uses the Linux /dev/urandom device for getting random keys and it uses the mmap system call to operate on the disk file efficiently, so it would take some modification to port to Windows. For now, it doesn't attempt to use any physical NVRAM. There's testing code that simulates NVRAM with a disk file, though of course that defeats the security of the whole scheme. The code also lets you root a keytree as a slot in another keytree, meaning you can operate multiple trees with just one NVRAM slot. Besides real NVRAM, making this thing useful needs some kind of database-like transaction scheme to improve reliability (if the current version crashes in the middle of an update, your keys can all be lost) and some kind of backup scheme (probably some kind of online synchronization of the tree with another tree on a remote computer). This was written mostly as an exercise but I tried to make it fast and solid enough to use for a real database if I feel paranoid enough to need it. Comments and suggestions types are welcome.