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.
Achtung : Auch SSL ist derzeit
unsicher