SCAN Definitions
and Conventions

Definitions

These documents use the terms "MUST", "SHOULD", and "MAY", and their negated forms, as defined in RFC 2119.

Categories for References

References are marked as being in one or more of the following categories:

"[Def]" - defines the algorithm,
"[Inf]" - gives additional information or an alternative description,
"[An]" - cryptanalysis (with either negative or positive implications for the algorithm's security),
"[Patent]" - patents or patent applications that may affect implementations of the algorithm,
"[Test]" - includes test vectors,
"[Impl]" - includes a reference implementation, written or endorsed by the algorithm designer(s). Note that in many cases these implementations are not optimised.

Security implications

Unless stated otherwise in the "Security comments:" sections, nothing is implied about the security of an algorithm simply by it being included on this list. There may be published attacks that are not listed in the security comments or references (if you know of any such attacks, please post them to sci.crypt).

Also, references to papers describing cryptanalysis of an algorithm should not be taken as necessarily implying that the algorithm is broken (often, a paper provides support for an algorithm rather than an attack on it, and attacks may or may not be practical).

Algorithm Parameters

Some algorithms have parameters, which are marked as one or more of "write", "read", and "creation". A "write" parameter can be set, and a "read" parameter can be read, after the algorithm object has been created. (In Java, this is done via the java.security.Parameterized interface.)

Any parameters given in parentheses following the algorithm name are "creation" parameters, and can be specified in the call used to create the algorithm object (in Java, as part of the name passed to getInstance). If there is more than one creation parameter, they are separated by commas, with no whitespace.

For example, the Java code:

    Mac.getInstance("HMAC(SHA-1)")

will create an object that implements the HMAC message authentication code, with "SHA-1" as the value of HMAC's digestName parameter. When a creation parameter refers to an algorithm, that algorithm may itself be parameterized, for example:

    Mac.getInstance("HMAC(HAVAL(32,5))"

An algorithm that depends on one or more other algorithms (as HMAC does in the above examples) is called a "construction".

Adding New Algorithms

If you would like to add an entry to the list, please cross-post it to the Usenet newsgroups comp.lang.java.security and sci.crypt, with a title that includes the tag "[SCAN]". The post should give the text of the proposed entry, in the same format as other algorithms of the same type, and should include at least:

references to at least one paper or web page describing the algorithm (preferably, although not necessarily, a paper published in a refereed journal).
any other useful references (cryptanalysis, home page, patents and patent applications, reference implementation, etc.)
if the references do not completely specify the algorithm (including input/output formats, etc.) in sufficient detail to allow interoperable implementations, then any missing details should be given.
test vectors, where available (without test vectors, an algorithm may not be regarded as completely specified).

comp.lang.java.security and sci.crypt should also be used to discuss corrections and additions to existing entries. (The list maintainer much prefers to handle these on newsgroups rather than via email, as it is important to get other cryptographers' comments about changes.)

Provisional Algorithm Names

If a provisional algorithm name is needed, it should start with a DNS domain belonging to the company or organisation that wishes to use it, followed by a colon.

For example, the Cryptix Development Team could use names beginning with "cryptix.org:", RSA Data Security Inc. could use names beginning with "rsa.com:", and so on. Note that these will be distinct from any standard names defined in the list, because they always contain a colon (':') character.

The above convention is only intended to provide provisional names for use during development, for application-specific algorithms, or in cases where interoperability with other software is not required. It is discouraged for algorithms that might have more general usefulness; these should be posted to comp.lang.java.security and sci.crypt as described above.

Changes to algorithms

An important principle is that once a listed algorithm has been accepted as fully specified, the algorithm itself never changes - not even if the change is apparently backward-compatible. Any revisions must be handled by assigning a new algorithm name.

On the other hand, it is possible to generalise an algorithm by adding extra creation parameters. For instance, a block cipher named "Foo" could be generalised to "Foo[(rounds)]", where (rounds) indicates the number of rounds to be used.

The rationale for forbidding even backward-compatible revisions is as follows: the JCA API (and any other API that may be adopted for languages other than Java) makes use of a list of security providers configured by the user or administrator, in order from most preferred to least preferred. When an algorithm name is looked up without specifying an exact provider, the first provider in preference order that supports the algorithm is used.

If compatible changes were allowed, an implementation of an old revision of an algorithm might 'mask' an implementation of a newer revision by a provider later in the preference order, which is obviously not desirable.

Algorithms that are colour-coded in red are not fully specified; these can be removed from the list at any time, or changed incompatibly.

Note that some of the citations in the "References:" sections are to draft standards. Where an algorithm is said to be "as defined in" a particular draft standard, the algorithm definition may change as the standard changes. Implementation or design based on these drafts is at the risk of developers (and users). Some of the referenced standards have a specific requirement that advertisements and documentation should not attempt to claim compliance with the standard until it has been finalized.

ASN.1 Object Identifiers

Where there is an ASN.1 OBJECT IDENTIFIER for an algorithm, the dotted-decimal form of the identifier is conventionally defined as an alias. These aliases should be the only names that match the syntax:

    ('0'-'9')+ ('.' ('0'-'9')+)*

(where "+" means one or more repetitions, and "*" means zero or more repetitions).

Conventions for symmetric ciphers

Ciphers that have different key schedules, but are otherwise identical are given different names (for example, SAFER-K and SAFER-SK, or RC4 and MARK-4). Sometimes it is useful to bypass the normal key scheduling process, and specify the subkeys (which should be random and independent) directly in the input key. The name of such a cipher is derived by adding "-ISK" to the standard name (except that if part of the name already specifies the key schedule, that part is dropped). For example, "DES-ISK" and "SAFER-ISK" refer to DES and SAFER respectively with independent subkeys. This convention can also be used for experimental ciphers that have no defined key schedule.

If the subkeys are not in fact random and independent (to a close-enough approximation), the cipher may become vulnerable to related-key attacks, and therefore particular care is needed from the application designer in choosing how to generate subkeys.

Subkeys are encoded in the order in which they are used for encryption (or if this is ambiguous, the order in which they are presented or numbered in the original document specifying the cipher). Where applicable, they have the same byte order as is used in the rest of the cipher. However, in some cases these conventions may still not be sufficient to decide how to encode the subkeys; if you wish to use an -ISK algorithm where the subkey encoding is not clear, ask for a comment to be added to the algorithm definition.

Viewing PDF and Postscript files

Most of the on-line references are in PDF and/or PostScript format. Versions of the Acrobat Reader^TM PDF viewer for several operating systems are available from Adobe's site:

To view PostScript files, you will need GNU or Aladdin Ghostscript, and either Ghostview or GSview, all of which are available from here. Note that in at least some versions of Netscape, compressed PostScript files (with filetypes ending .ps.Z or .ps.gz), seem to be downloaded incorrectly when the link to a file is clicked on directly. If you encounter this bug, it can be worked around by right-clicking on the link, selecting "Save Link As..." to save the compressed file, and decompressing it manually (on Windows, use a decompression utility that understands .Z and .gz formats, such as Winzip).

SCAN Definitions and Conventions