Transporter 1.4 build: 9639 released: 2006-03-06 compiled with: Java 1.8.0_131 Jet jet12.0-pro-x86/1.8.0_131

Lightweight Java classes to encrypt, digitally sign and armour to send sensitive information over the Internet without SSL.

Copyright: (c) 2004-2017 Canadian Mind Products.

Java application.
Download from: http://mindprod.com/products1.html#TRANSPORTER

----

Notes:

You must install the Java JRE to use this program.
See http://mindprod.com/jgloss/jgloss/jre.html

This program can only be used from the command prompt, (or via an command
line style icon shortcut) e.g. under Windows command.exe or JPSoft
tcmd.exe, formerly called the DOS box. Just clicking the programs in a
directory listing will not do anything useful. Just typing the program
names at the command prompt will not either.

This program requires a manual install! See below.

This program works with vanilla text files, (e.g. ASCII files or UTF-8
Unicode files). You will need a text editor to create and view them, not a word
processor. e.g. notepad, Visual Slick Edit or other suitable text editor
http://mindprod.com/jgloss/editor.html. You must use a monospaced font
http://mindprod.com/jgloss/monospacedfonts.html (aka fixed pitch, aka
programmer font) to view your files, or they won't look properly aligned.

I put out an avalanche of free software into the world, and submit PAD
files to hundreds of distribution sites, but I rarely hear back from
anyone.  What's happening?  Does it all just work fine?  It is so
complicated nobody can figure out how to use it and they give up on it?
It is it useful?  Since everyone has the source, do people just fix the
programs to their liking themselves?  Did you have trouble installing?  Do
I presume you know too much?  I would be happy to hear from you about your
experiences, positive or negative and your requests for improvements.  A
one-line email to roedy@mindprod.com would be great.

===> Free <===
Full source included.
You may even include the source code, modified or unmodified
in free/commercial open source/proprietary programs that you write and distribute.
May be used freely for any purpose but military.
For more details on this restriction, see
http://mindprod.com/contact/nonmil.html
If you include any Canadian Mind Products code in your own applications,
your app too must be labelled non-military use only.
http://mindprod.com/contact/nonmil.html
All Java jars and source code are included. If you need the class files or Javadoc, you will have to build them yourself. To streamline the zip downloads, class files and Javadoc have been removed.

----

Prerequisites:

This program runs under any OS that supports Java,
(e.g.W2K/XP/W2003/Vista/W2008/W7-32/W7-64/W8-32/W8-64/Linux/LinuxARM/LinuxX86
/LinuxX64/Ubuntu/Solaris/SolarisSPARC/SolarisSPARC64/SolarisX86/SolarisX64/OSX/AIX...)
so long as you have
<><> Java version 1.8 <><> or later installed (32-bit or 64-bit Java).
See http://mindprod.com/jgloss/installingjava.html for details.

----

Installing on a PC:

Download source and compiled jar files to run on your own machine as an application.
First install a recent Java JDK or JVM.
See http://mindprod.com/jgloss/installingjava.html.
To install, extract the zip download with WinZip
(or similar unzip utility) into any directory you please,
often J:\ --  ticking off the <span class="click">use folder names</span> option.
To run as an application, type:
java.exe %JAVA_OPTIONS -ea -jar J:\com\mindprod\transporter\transporter.jar {put any parms here}

adjusting as necessary to account for where the jar file is.

----

Installing on a MacIntosh:

Use Safari to download source and compiled jar files to run on your own machine as an application.
Safari will automatically unpack the zip into ~/Downloads (version 10.5)
[or on the Desktop (version 10.4 and earlier)].
First install a recent Java JDK or JVM.
See http://mindprod.com/jgloss/installingjava.html.
You may optionally move the download tree to a permanent home.
I don't have a MacIntosh, just a PC, so I can't test my Java programs for Mac compatibility.
In theory they should work without problems, but in practice that does not always happen.
If you have problems please, let me know, preferably with screenshots and complete verbatim error messages.
To run as an application, without parameters, just double click the jar file.

To run as an application with parameters, in bash shell type:
open Terminal.app
cd ~/Desktop
java.exe -ea -jar com/mindprod/transporter/transporter.jar {put any parms here}

adjusting as necessary to account for where the jar file is.

----

Rebuilding:

The zip already contains the necessary jar files, so unless you modify
the program, there is no need to recompile the source or rebuild the jar.
Configure.java basedir="E:/" in rebuild.xml to the drive where your files are.
Use ANT and rebuild.xml, not build.xml, to recompile and recreate the jar.

----

Use:

The transporter acts like an electronic secure courier to
deliver your data and documents in encrypted form safe from
prying eyes or those who would tamper with them.
It Encrypts, digitally signs and armours to send sensitive
information over the Internet without SSL.
Typically you would embed it in your own Internet
applications.
Applications include sending credit card information
collected by Applets to Servlets without a secure SSL
connection, sending credit card information via email,
sending secret messages and electronic voting.
The Transporter is a not normally used as a stand alone
application. You incorporate the Transporter classes in your own
Java programs.  The main limitation is that it is not
suitable for large files or streams.  The heavy duty RSA
encryption it uses too slow for sending large files.  On a
1.6 GHz machine, with 1024-bit keys, it can:
encrypt 200,000 bytes per second
decrypt 500 bytes per second
sign 5000 bytes per second
verify 200,000 bytes per second
If you use 4096-bit encryption these slow down to:
encrypt 50,000 bytes per second
decrypt 50 bytes per second
sign 50 bytes per second
verify 50,000 bytes per second
These classes are very simple.
They let you encrypt sensitive information to send over the
Internet or Email, without requiring secure SSL support. You
can encrypt and decrypt without JCE support. They use 256 to
4096 bit strong encryption, devised in Canada, so it is not
subject to America export restrictions.
They let you digitally sign information so that receiver
knows for certain who could possibly have sent it, and that
no one tampered with the information.
They armour information making it possible to send binary
information from Applets to servers via the CGI Servlet HTTP
POST interface, over email, raw sockets or even diskette or
CD.
The programs are simple enough that you can personally
verify they programs do exactly what they claim to without
any Trojan spy code.
To generate keys: specify a name for the key pair and
keysize 256..4096 The bigger the keysize, the more secure,
but the slower the encryption/decryption.
        java com.mindprod.transporter.MakeKeys yourname 1024
To test encryption and see examples of use see:
        java com.mindprod.transporter.Transporter
A simple send/receive using armouring and compression looks like this:
  import com.mindprod.transporter.Wrap;
  import com.mindprod.transporter.Unwrap;
  ...
  Anything originalMessage = new Anything( a, b, c );
  Wrap w = new Wrap();
  // you can send any Serializable object, including Strings and raw byte arrays.
  String transport = w.wrap( originalMessage );
  // transport String is sent to another machine... and then
  Unwrap u = new Unwrap();
  Anything reconstitutedMessage = (Anything)u.unwrap( transport );
Only the sender should have access to senderprivatekey.ser.
Only the receiver should have access to
receiverprivatekey.ser. There is no need to keep the public
keys secret from anyone.
Ideally sender and receiver should generate their own key
pairs using MakeKey and send the corresponding non-secret
public key to the other.
To encrypt, you need the receiver's public key.
To decrypt, you need the receiver's private key.
To sign, you need the sender's private key.
To verify a digital signature, you need the sender's public key.
senderprivatekey.ser and senderpublickey.ser must be used as
a pair. receiverprivatekey.ser and receiverpublickey.ser
must also be used as a pair. You may change the receiver
pair without changing the sender pair or vice versa.
Make backups of all keys. If you lose them there is no way
at all to read encrypted information.
If you had three computers exchanging information, each
acting as both sender and receiver, you would need 6 keys
altogether, a public and private key for each participant to
allow all possible combinations of encryption and signing.
You don't need a separate pair for each participant for
sending and receiving. You generate the public and private
key at the same time as a matched pair.
In practice you could get away with fewer keys, by reusing keys,
or not bothering with ones you don't need. For example, one common
situation would be to have the same receiver public key in every
Applet sending credit card information to a Servlet that has
a receiver private key -- only two keys altogether.
Design Philosophy
A major concern for anyone using any form of encryption is trusting the
author not to hide any trap doors in the code to snoop.  He also has to
trust government and military experts not to withhold some secret
technique to crack a proffered encryption algorithm or information about
their advanced hardware abilities to crack codes (e.g.  some sort of
quantum cracking).  The problem is modern cryptography is highly complex.
What I have done is pare the encryption logic down to the bone so that it
would be simple enough for the average Java programmer to understand line
by line, and ensure himself the program does exactly what it claims to.  I
used the mathematically Spartan RSA algorithm.  This means the program is
missing features like hybrid symmetric key, AES and chaining that would
have increased its speed and resistance to cracking.  I have also posted
the source for anyone to examine.  There are thus more eyes looking for
anything improper, possibly accidental.  To verify my code, you would also
want to verify Java's secret key generator.  If in any way it were not
secure, the whole encryption scheme would be a house of cards.  If you are a diplomat
and need 100% uncrackabilty, you should probably not be using commercial
software.  Your people should write your own one-time-pad software.  The
Soviets used a one-time paper one time pad system successfully for years.
see http://mindprod.com/project/uncrackableencryption.html
The Downside of Any Encryption
Using any sort of encryption flags to the attention of snoopers that you
are trying to hide something.  They can then bring in their experts and
computers to crack the code.  There is a whole field called steganography
about how to hide information in images, e.g.  porn, which gets lost in
the torrents of images flying over the net.  Even the tiniest error in the
program or use of it greatly simplifies their task.  The security of
Windows is so weak, it is trivial for criminal or government agencies to install a
keystroke logger than looks at everything you type before you encrypt it.
Today, with massive wiretapping by the government, your only hope is messages that
have perfectly innocuous meaning that don't trip any filters.
Distributing Keys
A private key should never leave the machine it was
generated on, except for backup. You can distribute public
keys without worry about others snooping. It does not matter
if they snoop. These are PUBLIC keys, after all. You can
distribute them via ordinary email either as simple
attachments, or wrapped and embedded in the message. You
could also post them on a website.
The transporter requires only Java 1.2 for Wrap and Encrypt. It
depends only on the BigInteger class, not the JCE (Java
Cryptography Extensions). Sign uses the
MessageDigest.getInstance( "MD5" ) method of the JCE which
was not bundled officially with Java until 1.4, though was
available separately earlier.
Why the suitcase icon?  It symbolises a secure courier who
transports diplomatic papers in a briefcase chained to his
wrist.
Thomas Pornin wrote this criticism:
"You appear to encrypt messages by blocks with RSA, with ECB
chaining, aka "no chaining at all".  This combines the weaknesses of
ill-used symmetric ciphers with the slowness and waste of space of RSA.
If you used a symmetric encryption with RC4, with a random secret key
which is then ecrypted with RSA, then you would have something much
stronger, faster, with more compact messages, and it would not use more
code."
I wrote the Transporter a long time ago to get an understanding of how
public/private key encryption worked probably before JCE came out or at
least before it was bundled.  I intended it for short messages, such as a
credit card number so I was not too worried about speed or fluffiness.
That is why I did not use a more complex hybrid of RSA and symmetric ciphers.
Key generation is very slow. For short messages, my scheme is thus faster
since it does not need to generate a session key.
Someone might use the Transporter today because they can control all
the code.  JCE is a large, complex black box you are just supposed to
trust.  How do you know JCE does not contain deliberate trap doors put
there at the insistence of the Homeland security people?
Caveats
Even with the Transporter, those snooping know whom you are sending to,
and can trace the message to where they are.  They know when you send
messages and how long those message are.  If they can corrupt your
machine, they can log all your keystrokes.  Then anything the Transporter
does is useless.  You can embed messages is web pages.  Then everyone who
reads the page gets it, but only the one with the private key can read it.
Then is it not clear to snoops who was the actual target of the message
(though they know it was one of the visitors).


----

Version History:

 1.4 2006-03-06 reformat with IntelliJ and add Javadoc.

-30-