(En)Crypter 2.1
If you want to write me a private email message, you can do that here:
Please send this as 'plain text' only.
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).
- 2015-11-01
The repository is now available via github:
https://github.com/omoeller/cramshou
I have cleaned up up a bit and added instructions (HOWTO.txt)
- 2004-11-20
A Test Suite for validation of the Key-Generator and
character encoding has been added. It runs on Lin*x and Windows (using Cygwin make).
- 2004-10-24
There have been conversion problems of non-ASCII characters in older
Crypter versions, in particular when encrypting files from command-line.
These are fixed in the 2.0.12 (and higher) versions, please
report problems here.
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.
... is a quite recent, practicable and provably secure (in some sense and
under some reasonable assumptions). Please read more about
the Cramer-Shoup system.
are only three small files (also available at github):
:
- 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 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
- a bit pattern 1000 1000 1000 1000 (via Crypter)
- via the CryptoModule (also those generated by KeyGeneratorCS)
with random patters (01|10)*
Using untruncated-decrypt (or u for short)
instead of decrypt switches off the truncation of surplus bits
when decrypting.
To generate your own key pairs, you can download the following java files to a
separate directory:
and do the following:
javac KeyGeneratorCS.java
java KeyGeneratorCS -f CryptoModule.java
-o "YOUR NAME <YOUR@EMAIL>"
-n KEYNAME
1042
javac -classpath . CryptoModule.java Crypter.java
Now you should be able to encrypt and decrypt by command line:
java Crypter e MESSAGE_FILE ENCRYPTED_FILE
java Crypter d ENCRYPTED_FILE [OUTPUT_FILE]
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 CryptoModule.java 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 CryptoModule.java, there is no
secret key in the .class files. Make ONLY THOSE (!) class files available on
the net
The java key generator (KeyGeneratorCS.java) 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.
You can obtain a suite for running own tests as a zip file:
testCrypter.zip
This contains the files
M Filemode File
- ---------- --------------------------------
-rw-r--r-- testCrypter/check_random_message
-rw-r--r-- testCrypter/Crypter.java
-rw-r--r-- testCrypter/KeyGeneratorCS.java
-rw-r--r-- testCrypter/Makefile
- ---------- --------------------------------
After un-zipping, go to directory ./testCrypter and call
make
This will run a (large) set of tests of the following form:
- generate a new pair of keys of a specified length
- with this pair, do for a number of messages sizes:
- generate a random message (using /dev/rand, if possible)
- encrypt the message, decrypt it again
- compare original message with decrypted message
- if the comparison fails, STOP
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.
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 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
1000,- DKK
for the first one who proves me wrong here!
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.
You might have noticed some obvious extentions to this applet.
- Enable other secret/public key pairs (e.g. by menu bar)
- Since it is a randomised 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.
So far none. But please email me, if you detect some (even if they do not
compromise the security).
LAST VALIDATION:
01 NOV 2015
webmaster -
Last modified: Sun Nov 1 14:12:35 2015
