One-Time Pad Generator One-Time Pad GeneratorThis 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.
The case of letters in keys generated with Word-like, Alphabetic, and Gibberish key text will be as chosen. 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. Selecting “Mixed case” creates keys with a mix of upper- and lower-case letters; such keys are more secure than those with uniform letter case, but do not pass the “telephone test”: you can't 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 to create the seed, the seed 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:
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 judgment, and you can form your own conclusions based on their analysis.
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 of this page to examine the code, including the copyright notice and conditions of use. The MD5 algorithm was developed by Ron Rivest.
|
This document is in the public domain.