my Homepage Home my personal Linkpage Links MagicSphere FindPage Technical Literature (CS) BLIP Google Google

(En)Crypter 2.1

If you want to write me a private email message, you can do that here: WORX!
  [original message will be destroyed -- go here for a version without forms]
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-representation, 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).

Recent Changes!NEW!

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 (also available at github): : You are welcome to copy and customise them.
If you want to play with the system try some en-/decryption online here.
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]

From Version 2.0 on, you can trustfully set the byte-width both for en- and for decrypting. Reasonable settings are:
   -7 : only text, 8-th bit will be assumed 0
   -8 : default, allows for iso-latin1 characters
  -16 : wide characters
For iso-characters (German umlauts) or binary files, use -8, which is also the default. You can used the option from command line, e.g., with
   java Crypter e -8 BINARY_FILE [OUTPUT_FILE]
Of course, en- and de-cryption have to use the same number of bits. In the generated crypto-Text you can see the number of Bits in field "Bits per Char:". From Version 2.1 on, padding is per default made by Using untruncated-decrypt (or u for short) instead of decrypt switches off the truncation of surplus bits when decrypting.

Using it for OWN secret/public keys

To generate your own key pairs, you can download the following java files to a separate directory: and do the following:
   java KeyGeneratorCS -f -o "YOUR NAME <YOUR@EMAIL>" -n KEYNAME 1042
   javac -classpath .

Now you should be able to encrypt and decrypt by command line:

If you plan to make the public key encryption available on the web (as done here), you have to make a copy of the the and to a different directory modify this copy as follows:
   !!! Replace the data in the SECRET KEY part !!!
For example use:
    byte[] x1 = { 0 } ;
    byte[] x2 = { 0 } ;
    byte[] y1 = { 0 } ;
    byte[] y2 = { 0 } ;
    byte[] z = { 0 } ;

When you compile this such modified, there is no secret key in the .class files. Make ONLY THOSE (!) class files available on the net

The cryptographic keys

The java key generator ( is rather recent. Therefore my keys 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 possible 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.

Validation: a Test Suite

You can obtain a suite for running own tests as a zip file:
This contains the files
M Filemode     File
- ----------   --------------------------------
  -rw-r--r--   testCrypter/check_random_message
  -rw-r--r--   testCrypter/
  -rw-r--r--   testCrypter/
  -rw-r--r--   testCrypter/Makefile
- ----------   --------------------------------
After un-zipping, go to directory ./testCrypter and call
This will run a (large) set of tests of the following form: You can modify the parameters which key lengths to try, which message lengths to try, and which bit encoding (7/8) to use in the Makefile.

Of course you can use the enclosed Crypter/ KeyGeneratorCS as well to create your own keys.

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: Though the answer to most of the above would with all likelihood 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 favourite 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
for the first one who proves me wrong here!

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. 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).


Counter started on 23/12/2001
webmaster - Last modified: Sun Nov 1 14:12:35 2015