This page has officially moved to	http://www.verify-it.de/sub/crypter.html
Please update your bookmarks.	23/12/2001

(En)Crypter 1.4

If you want to write me a private email message, you can do that here: WORX!

Please send this as 'plain text' only.

What happens here?

The message you enter is handed to a small applet running invisible inside your web browser. Here, the message gets translated to a sequence of big numbers. Those are encrypted using a the public part of a public-key system described below. Afterwards, they are mapped into a base64-respresentation, thus the encrypted text can be sent by (almost) every mail system - to me.
If everything works fine, a 'send mail' window will pop up all by itself and you just have to confirm it (and, possibly add a subject - which will not be encrypted, so don't write anything revealing here).

Why is this secure?

Everybody can encrypt, but nobody but me can decrypt. That's what a public key algorithm is all about. It can be only relatively secure, for the secret key can be 'guessed' and validated by an attacker. But the problem of doing this can be considered infeasible for large keys. The key has a 2014 bit prime modulus, which is a pretty high standard. For I computed the prime moduli and implemented both key-generation and crypto algorithm myself, this is as trustworthy as it can get.

The Cramer Shoup Cryptosystem

... is a quite recent, practicable and provably secure (in some sense and under some reasonable assumptions). Please read more about the Cramer-Shoup system.

The Sources

are only three small files:

crypter.html (this html page, hold down shift an click in order to save to file)
Crypter.java (the Java applet with panel)
CryptoModule.java (the implementation of the crypto algorithm containing the public key)

You are welcome to copy and customize them.
From Version 1.4 on, there is also the possibility to encrypt from command line, provided you have a proper Java installation:
java Crypter e MESSAGE_FILE [OUTPUT_FILE]

How 'secure' is this...?

Be not deceived. Absolute security is not feasible in public key encryption, though some enthusiastic newspaper articles try to convince you otherwise. But even if the problem was not the "inherent guessability" of the secret key, there are a lot of questions beyond that:

How secure is the software you are using? Could it do something complete unintended and undetected (e.g. automatically email the file you just decrypted, to some interested listener)?
How secure is the operating system you are using? Has somebody the right to access your files or your memory (or could acquire this right)? Does it produce 'junk' like ~.tmp files, auto-save files or core dumps, that can be used to figure out what you have been writing in first place?
(If you think this is far fetched, feel free to read about a real Moby Hack nobody noticed until the author revealed it)
How secure is the hardware you are using? Could somebody physically 'steal' your secret key? Or just trace the signal connected to your screen?
How secure is the environment you are in? Could somebody optically monitor the screen, the keyboard or... you?

Though the answer to most of the above would with all likelyhood be "Yes" , this is no reason to be paranoid. After all - how much pain would someone undergo just to read your email or your files? But I believe it is important to remember that just some nice and advanced math does not get rid of these problems.
The only thing, this small Applet can do, is offering a partial remedy to the first concern. You still have to trust Java and your favorite browser not to do something unintended with your data. But you can check the code, for it is small (and this is not the case for open source software like PGP). And you can read the paper and convince yourself of the correctness. It is hard to offer anything better here.

I am convinced, that this system is not breakable in practice. In fact, I'm offering a prize of

1000,- DKK for the first one who proves me wrong here!

The keys

They were computed on a separate hardware with a allegro common lisp program. Trusting the bignum routines there and also some advanced prime number algorithms, I believe they are 'correct' ,i.e. the generators are really suchlike (which is asserted by falsifying all other possilbe orders) and the prime moduli are really prime (which is corroborated by a Millner-Rabin pseudo-primality test).
If you belive, anybody could comfortably compute the discrete logarithm from a 2014 bit number, you can also use a 5020 bit key, but be warned that this can last some hours.

Why is it so slooooooow?

The cryptographic algorithm has to deal with long integers (some 2000 bits). And after all, Java is an interpreted language. It might take up to some minutes to encrypt (or decrypt) a text. The best (and only) thing to to is to start an encryption and then just do something else.
Please note that the computation time is not a linear increasing function of the input length, due to the fixed prime modulus. Everything below 250 Characters will take about the same time, then everything below 500 characters twice this time and so on.

Things to do

You might have noticed some obvious extentions to this applet.

Enable other secret/public key pairs (e.g. by menue bar)
Provide a key generation method
Provide a generator for the big prime modulus
Since it is a randomized encryption, add some random seed generator (at the moment I just use the one Java provides; my claim is that this does not really compromise security)

I cannot promise to do any of the above soon, for I am really busy with other objectives.

Known Bugs

So far none. But please email me, if you detect some (even if they do not compromise the security).

LAST VALIDATION: 20 December 2001

Oliver Möller - Last modified: Sun Dec 23 17:27:33 2001