
SafeMail uses a proprietary Russian algorithm.
Maybe it is GOST. Schneir covers it, and there is a white paper on it at the b_crypt site.
I spoke with a fellow there for about 20 minutes today about their program. Sounded like these guys are just front-ends and obviously know nothing about the technology. (Couldn't answer how many bits of the "22 character" key were in use) He did assure me it wasn't GOST, or anything published. Story was that a Russian emigrant (sp?) came over to the US and this is his algorithm. Apparently this person is not willing (at this time) to put the algorithm out for public review. I spent most of my time pushing for some sort of peer review. Supposedly they have talked with Schneier and Denning, about the method but neither has done more than talk with them briefly about the method. (I understood from what he said that they weren't willing to pay Bruce what it would take to do a through review. ;-) I also spent some time educating them about PGP and how it does do compression, ASCII armour, etc. All in all they guy was plesant enough, but no real details on how the system works. What I got was that they "private" key is what you type in. This is then hashed (he even used the word hash) into a 22 character public key that you share with your friends. Even at 8 bits/charcter, 176 bits doesn't sound secure for a public key algorithm, but then again this isn't RSA we are looking at. All in all it still sounds like snake oil to me! Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke@aud.alcatel.com Richardson, TX

Not to defend the safemail folks, but this does remind me of something that NeXT did with Eliptic curve based systems; there was no storage of the private key, it was generated from the passphrase at run time. It was a side discussion, maybe with Andrew Lorenstien? Andrew? Daniel R. Oelke wrote: | All in all they guy was plesant enough, but no real | details on how the system works. What I got was that | they "private" key is what you type in. This is then | hashed (he even used the word hash) into a 22 character | public key that you share with your friends. | Even at 8 bits/charcter, 176 bits doesn't sound secure | for a public key algorithm, but then again this isn't | RSA we are looking at. -- "It is seldom that liberty of any kind is lost all at once." -Hume

Adam Shostack writes:
Not to defend the safemail folks, but this does remind me of something that NeXT did with Eliptic curve based systems; there was no storage of the private key, it was generated from the passphrase at run time.
Yup, NeXT did this with their "For Your Eyes Only" demo and the crypto extensions for their Mail application. Although NeXT used an algorithm called "FEE" (Fast Elpitic Encryption), you can do it with RSA by hashing the passphrase, seeding a random number generator, generating a random prime, etc... It works but it adds a lot of processing time to encryption and decryption. There are other, more serious, drawbacks to such a scheme though. You can't change your passphrase without changing your public key. People can try to guess your passphrase with only your public key. Crack can guess peoples account passwords something like 24% of the time. I doubt the average joe would use much better passphrases for their secret key. That's a scary thought!! At least with PGP someone has to get a copy of the encrypted secret key first. One interesting thing about NeXT's software is that the Mail application has crypto hooks. The crypto code is in a drop-in bundle that extends the app at runtime. This isn't just a generic interface, but the internationally shipped Mail software calls methods in the external bundle that are definitely crypto related. Also, much of the crypto and key management user interface ships with the main Mail package. It is hidden without the crypto bundle, but if you peek around with InterfaceBuilder you can see that it is there. andrew

And more generally, this is what NeXT's developer documentation has to say about services... Good stuff. -Declan ---- Examples of a Few Possible Services Here are a few examples of services that have already been implemented to give you an idea of what can be done with NeXTSTEP's services mechanism: * Encryption An encryption service can convert data to a more secure form. For example, Mail can place a mail message on the pasteboard as a standard Rich Text Format (RTF) document, and another application could encrypt the document and place it back into mail as unreadable ASCII text, or as a document to be opened only by another external decryption application. Excerpts from internet.cypherpunks: 20-Jun-96 Re: Safemail by Andrew Loewenstern@il.us
One interesting thing about NeXT's software is that the Mail application has
crypto hooks. The crypto code is in a drop-in bundle that extends the app at runtime. This isn't just a generic interface, but the internationally shipped Mail software calls methods in the external bundle that are definitely crypto related. Also, much of the crypto and key management user
interface ships with the main Mail package. It is hidden without the crypto
bundle, but if you peek around with InterfaceBuilder you can see that it is there.

Excerpts from internet.cypherpunks: 20-Jun-96 Re: Safemail by Adam Shostack@homeport.o
Not to defend the safemail folks, but this does remind me of something that NeXT did with Eliptic curve based systems; there was no storage of the private key, it was generated from the passphrase at run time. It was a side discussion, maybe with Andrew Lorenstien? Andrew?
Might you be thinking of ForYourEyesOnly, by R. Crandall and J. Martin? It was distributed as a demo program with Release 2 of the NeXTstep operating system, along with such nifty apps as a Mandelbrot generator that used the 56001 onboard DSP. (I've never used it, though.) Here's the help file that comes with ForYourEyesOnly. I had to grab it with SegHoarker. -Declan (Registered NeXT Developer) --- General ForYourEyesOnly is a message encryption utility. The basic idea is that secret messages may be sent via mail, or simply stored as encrypted (.encr) files. The notion of Public Key encryption requires that each participant have a pair of keys: a "Private Key" and an associated "Public Key." Everyone's Public Key is known to everyone (hence the name public). Private Keys on the other hand are just like passwords; that is, you commit your Private Key to memory. Keys You create your Public Key via the Registration... menu item. When your (at least 8-character) Private Key is entered, the associated Public Key is computed for you. Again, note that the Public Key is safe, i.e. it can be broadcast to the whole world. Your Private Key, on the other hand, should never be disclosed beyond your chosen group of confidantes (which group can of course be just a singleton--you). ForYourEyesOnly allows for groups (larger than just yourself) to share a Private/Public Key pair. For example, a sales department can have one common Private Key, so that any member of sales may read mail that was encrypted using the associated Public Key for sales. In this "group" mode, a new sales member is presumably given the Private Key verbally, on a garden walk, or during a loud evening at a local tavern, etc. Decryption The decryption procedure is dealt with first in case you have just received an encrypted document and don't know what to do with it. If this is the case you may, for example, have double clicked a .encr file icon from mail and have landed here. By entering a correct Private Key in the Message Window and pressing the Decrypt button you will obtain a decrypted file. You might wonder how someone could have sent you an encryption if you have not yet registered a Private Key. Well, you might just have joined a department all of whose workers are using a single Private/Public Key pair for intra-office mail. In this case, all you need do is find the departmental Private Key for decryption. The .encr icons can be dragged to/from Mail or to/from Browser. Encrypting files A Plaintext message may be encrypted by entering the recipient's Public Key (if it has not already appeared automatically, as it does when the recipient initiated a mail exchange), and your own Private Key, then pressing the Encrypt button. (As above, a Public Key must have been obtained at some point in the past via the Registration menu item). Note that "Plaintext" is actually a theoretical term from encryption theory, and means the original, understandable text. What you can actually send, though, is text and/or pictures, etc., much the same way that you can mail multimedia files. We call all of this Plaintext, and the encryption algorithm chews up everything you are sending in order to create the .encr file. (NOTE: You can encrypt any kind of file, but at this Release you cannot send directories (folders)). The encrypted file icon will appear in the icon well at the top of the message window and can be dragged to the file browser or another application. The encrypted message can also be sent via the Services menu by selecting the Mail menu and the Document menu item under that. A file can also be encrypted and saved to disk in a place you specify by selecting the Encrypt, then Save As... menu item under the Document menu. Instant Rebounding Note that ForYourEyesOnly automatically transmits the Public Key of the sender along with the message itself. Thus, when you decrypt a mail message you will get an automatic display of the other party's Public Key. This convenience means that once you have decrypted the incoming message, you can easily "rebound", that is shoot a message back, simply by editing the Plaintext area and hitting the Encrypt button. This instant rebounding works because both necessary keys are properly in place as soon as you decrypt. Importing files Files can be dragged in from the browser to the content of the message window, or selected using the Import File... menu item in the Document menu. Exporting files Files in a received Plaintext message can be exported by dragging them from the message window content or by double clicking them to launch the appropriate application. Our proprietary algorithm One enjoyable aspect of working on encryption algorithms is that Help information pertaining to the algorithm itself should be vacuous; i.e., the less said, the better. Just one remark: the algorithm uses number theory but, in not using factorization, is distinct from the celebrated RSA method.
participants (4)
-
Adam Shostack
-
Andrew Loewenstern
-
Declan B. McCullagh
-
droelke@rdxsunhost.aud.alcatel.com