One-Time Pad Generator
This page, which requires that your browser support JavaScript
(see Why JavaScript below),
generates one-time pads or password lists in a variety of
forms. It is based a high-quality pseudorandom sequence
generator, which can be seeded either from the current date
and time, or from a seed you provide. Fill in the form below
to select the format of the pad and press "Generate" to
create the pad in the text box. You can then copy and paste
the generated pad into another window to use as you wish.
Each of the labels on the request form is linked to a description
of that parameter.
Each of the fields in the one-time pad request form is described
below.
Enter the number of keys you'd like to generate. If you generate
more than fit in the results text box, you can use the scroll
bar to view the additional lines.
Lines in the output will be limited to the given length (or contain
only one key if the line length is less than required for a single
key). If the line length is greater than the width of the results
box, you can use the horizontal scroll bar to view the rest of the
line. Enter 0 to force one key per line; this is handy
when you're preparing a list of keys to be read by a computer program.
Each key will contain this number of characters, not counting
separators between groups.
If a nonzero value is entered in this field, the key will be broken
into groups of the given number of characters by separators. Humans
find it easier to read and remember sequences of characters when
divided into groups of five or fewer characters.
This set of radio buttons lets you select the character set used in
the keys. The alternatives are listed in order of
increasing security.
- Numeric
- Keys contain only the decimal digits "0" through "9".
Least secure.
- Word-like
- Keys are composed of alphabetic characters which obey the
digraph statistics of English text. Such keys contain
sequences of vowels and consonants familiar to speakers
of Western languages, and are therefore usually easier to
memorise but, for a given key length, are less secure than
purely random letters.
- Alphabetic
- Keys consist of letters of the alphabet chosen at random.
Each character has an equal probability of being one of
the 26 letters.
- Gibberish
- Keys use most of the printable ASCII character set, excluding
only characters frequently used for quoting purposes. This
option provides the greatest security for a given key length,
but most people find keys like this difficult to memorise or
even transcribe from a printed pad. If a human is in the loop,
it's often better to use a longer alphabetic or word-like key.
Most secure.
If this box is checked, keys generated with Word-like, Alphabetic,
and Gibberish key text will contain only upper-case (capital)
letters. Most people find it easier to read lower case letters
than all capitals, but for some applications (for example, where
keys must be scanned optically by hardware that only
recognises capital letters), capitals are required. Checking
this box when Key text is set to Gibberish causes the Gibberish
keys to contain only capitals instead of a mix of upper- and
lower-case letters; such keys are said to pass the "telephone
test": you can read them across a (hopefully secure) voice link
without having to indicate whether each letter is or is not
a capital.
When the Key length is longer than
a nonzero Group length specification,
the key is divided into sequences of the given group length
by separator characters. By default, a hyphen, "-", is used
to separate groups. If you check this box, separators will be
chosen at random among punctuation marks generally acceptable
for applications such as passwords. If you're generating passwords
for a computer system, random separators dramatically increase
the difficulty of guessing passwords by exhaustive search.
When this box is checked, at the end of the list of keys, preceded by
a line beginning with ten dashes "-", the 128 bit MD5 signature of
each key is given, one per line, with signatures expressed as 32
hexadecimal digits. Key signatures can be used to increase security
when keys are used to control access to computer systems or databases.
Instead of storing a copy of the keys, the computer stores their
signatures. When the user enters a key, its signature is computed
with the same MD5 algorithm used to generate it initially, and the key
is accepted only if the signature matches. Since discovering
a key which will generate a given signature is believed to be
computationally prohibitive, even if the list of signatures stored on
the computer is compromised, that information will not permit an
intruder to deduce a valid key.
Signature calculation is a computationally intense process for which
JavaScript is not ideally suited; be patient while signatures are
generated, especially if your computer has modest
processing speed.
For signature-based validation to be secure, it is essential
the original keys be long enough to prohibit discovery of matching
signatures by exhaustive search. Suppose, for example, one used
four digit numeric keys, as used for Personal Identification
Numbers (PINs) by many credit card systems. Since only 10,000
different keys exist, one could simply compute the signatures of
every possible key from 0000 through 9999, permitting an attacker who
came into possession of the table of signatures to recover the
keys by a simple lookup process. For maximum security, keys must
contain at least as much information as the 128 bit signatures
computed from them. This implies a minimum key length (not counting
non-random separator characters) for the various key formats as
follows:
| Key Composition | Minimum Characters
|
|---|
| Numeric | 39
|
| Word-like | 30
|
| Alphabetic | 28
|
| Gibberish | 20
|
It should be noted that for many practical applications there is no
need for anything approaching 128-bit security. The guidelines above
apply only in the case where maximum protection in the event of
undetected compromise of key signatures occurs. In many
cases, much shorter keys are acceptable, especially when it is assumed
that a compromise of the system's password or signature database would
be only part of a much more serious subversion of all resources
on the system.
The seed is the starting value which determines all
subsequent values in the pseudorandom sequence used to generate
the one-time pad. Given the seed, the pad can be reproduced. The
seed is a 31-bit number which can be derived from the date and
time at which the one-time pad was requested, or from a
user-defined seed value. If the user-defined seed consists
entirely of decimal digits, it is used directly as the seed,
modulo 231; if a string containing non-digit characters
is entered, it is used to compute a hash code which is
used to seed the generator.
When the clock is used as the seed, the clock value is entered
in the User-defined box to allow you, by checking "User-defined",
to produce additional pads with the same seed.
At first glance, JavaScript may seem an odd choice for programming
a page such as this. The one-time pad generator program is rather
large and complicated, and downloading it to your browser takes longer
than would be required for a Java applet or to transfer a
one-time pad generated by a CGI program on the Web server. I chose
JavaScript for two reasons: security and transparency.
Security.
The sole reason for the existence of one-time pads is to
provide a source of information known only to people to whom
they have been distributed in a secure manner. This means
the generation process cannot involve any link whose security
is suspect. If the pad were generated on a Web server and
transmitted to you, it would have to pass over the
Internet, where any intermediate site might make a copy
of your pad before you even received it. Even if some
mechanism such as encryption could absolutely prevent the
pad's being intercepted, you'd still have no way to be sure
the site generating the pad didn't keep a copy
in a file, conveniently tagged with your Internet address.
In order to have any degree of security, it is essential
that the pad be generated on your computer, without
involving any transmission or interaction with other
sites on the Internet. A Web browser with JavaScript makes
this possible, since the generation program embedded in this
page runs entirely on your own computer and does not
transmit anything over the Internet. Its output appears
only in the text box, allowing you to cut and paste it
to another application. From there on, its security is
up to you.
Security is never absolute. A one-time pad generated with
this page might be compromised in a variety of ways, including
the following:
- Your Web browser and/or JavaScript interpreter may
contain bugs or deliberate security violations
which report activity on your computer back to some
other Internet site.
- Some other applet running on another page of your
browser, perhaps without your being aware of its
existence, is spying on other windows.
- Some other application running on your computer
may have compromised your system's security and
be snooping on your activity.
- Your Web browser may be keeping a "history log"
or "cache" of data you generate. Somebody may
come along later and recover a copy of the pad
from that log.
- The implementation of this page may contain a bug
or deliberate error which makes its output
predictable. This is why transparency,
discussed below, is essential.
- Your computer's security may have been compromised
physically; when's the last time you checked that a
bug that transmits your keystrokes and/or screen
contents to that white van parked down the street
wasn't lurking inside your computer cabinet?
One can whip oneself into a fine fever of paranoia worrying about
things like this. One way to rule out the most probable risks
is to download a copy of the generator page and run it
from a "file:" URL on a computer which has no network
connection whatsoever and is located in a secure location
under your control. And look very carefully at any files
created by your Web browser. You may find the most interesting
things squirreled away there....
Transparency.
Any security-related tool is only as good as its design
and implementation. Transparency means that, in
essence, all the moving parts are visible so you can judge
for yourself whether the tool merits your confidence. In
the case of a program, this means that source code must
be available, and that you can verify that the program
you're running corresponds to the source code provided.
The very nature of JavaScript achieves this transparency.
The program is embedded into this actual Web page; to
examine it you need only use your browser's "View Source"
facility, or save the page into a file on your computer
and read it with a text editor. JavaScript's being
an interpreted language eliminates the risk of your running
a program different from the purported source code: with
an interpreted language what you read is what you run.
Transparency is important even if you don't know enough about
programming or security to determine whether the program
contains any flaws. The very fact that it can be examined
by anybody allows those with the required expertise to pass
judgement, and you can form your own conclusions based on
their analysis.
Credits
The pseudorandom sequence generator is based on L'Ecuyer's
two-sequence generator as described in
Communications of the ACM, Vol. 31 (1968), page 742.
A Bays-Durham shuffle is used to guard against regularities
lurking in L'Ecuyer's algorithm; see
ACM Transactions on Mathematical Software, Vol. 2 (1976)
pages 59-64 for details.
The JavaScript implementation of the
MD5 message-digest algorithm
was developed by Henri Torgemane; please view the
source code for this page to examine the code, including the copyright
notice and conditions of use. The MD5 algorithm was developed by Ron Rivest.
Additional information regarding MD5 can be found at the
RSA Data Security, Inc. site.
by John Walker
May 26, 1997
This document is in the public domain.