The SSH server usually runs as root (as does the client, in some circumstances). At various
points, SSH needs to access files belonging to the source or target accounts. The root
account privilege overrides most access controls, but not all. For instance, the root account
on an NFS client doesn't necessarily have any special access to files on a remote
filesystem. Another example is POSIX access control lists (ACLs); only the file owner can
change a file ACL, and root doesn't override this restriction.
In Unix, there is a way for a process to take on the identity of a different user than its current user ID: the setuid system call. Root can use this facility to "become" any user. However, this call is irreversible for the duration of the process; a program can't regain its previous privileges, making setuid unsuitable for SSH. Some Unix implementations have a reversible form, seteuid (set effective user ID), but it isn't universally available and isn't
[20]
part of POSIX.
To aid in portability, SSH1 and SSH2 use the reliably available setuid system call. The first time they need to access a file as a regular user, they start a subprocess. The subprocess calls setuid to change (irrevocably) to the desired uid, but the main SSH program continues running as root. Then, whenever SSH needs file access as that user, the main program sends a message to the subprocess, asking it to perform the needed operation and return the results. Internally, this facility is called the userfile module.
Keep this behavior in mind when debugging an SSH process with SunOS trace, Solaris truss, Linux strace, or another process tracer. By default, these programs trace only the topmost process, so always remember to trace subprocesses as well. (See the tracer's manpage for the appropriate option, though it is usually -f. ) If you forget to do this, and the problem is with file access, you might not see it, since the userfile subprocess performs the file-access system calls (open, read, write, stat, etc.).
[20]
Actually, POSIX does have the same feature under a different name, but it isn't always
present, either.
In Unix, there is a way for a process to take on the identity of a different user than its current user ID: the setuid system call. Root can use this facility to "become" any user. However, this call is irreversible for the duration of the process; a program can't regain its previous privileges, making setuid unsuitable for SSH. Some Unix implementations have a reversible form, seteuid (set effective user ID), but it isn't universally available and isn't
[20]
part of POSIX.
To aid in portability, SSH1 and SSH2 use the reliably available setuid system call. The first time they need to access a file as a regular user, they start a subprocess. The subprocess calls setuid to change (irrevocably) to the desired uid, but the main SSH program continues running as root. Then, whenever SSH needs file access as that user, the main program sends a message to the subprocess, asking it to perform the needed operation and return the results. Internally, this facility is called the userfile module.
Keep this behavior in mind when debugging an SSH process with SunOS trace, Solaris truss, Linux strace, or another process tracer. By default, these programs trace only the topmost process, so always remember to trace subprocesses as well. (See the tracer's manpage for the appropriate option, though it is usually -f. ) If you forget to do this, and the problem is with file access, you might not see it, since the userfile subprocess performs the file-access system calls (open, read, write, stat, etc.).
[20]
Actually, POSIX does have the same feature under a different name, but it isn't always
present, either.
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 3. Inside SSH
3.7 Randomness
Cryptographic algorithms and protocols require a good source of random bits, or entropy. Randomness is used in various ways:
3.7 Randomness
Cryptographic algorithms and protocols require a good source of random bits, or entropy. Randomness is used in various ways:
-
● To generate data-encryption keys
-
● As plaintext padding and initialization vectors in encryption algorithms, to help foil
cryptanalysis
-
● For check bytes or cookies in protocol exchanges, as a measure against packet
spoofing attacks
Randomness is harder to achieve than you might think; in fact, even defining randomness is difficult (or picking the right definition for a given situation). For example, "random" numbers that are perfectly good for statistical modeling might be terrible for cryptography. Each of these applications requires certain properties of its random input, such as an even distribution. Cryptography, in particular, demands unpredictability so an attacker reading our data can't guess our keys.
True randomness-in the sense of complete unpredictability-can't be produced by a computer program. Any sequence of bits produced as the output of a program eventually repeats itself. For true randomness, you have to turn to physical processes, such as fluid turbulence or the quantum dice of radioactive decay. Even there, you must take great care that measurement artifacts don't introduce unwanted structure.
There are algorithms, however, that produce long sequences of practically unpredictable output, with good statistical randomness properties. These are good enough for many cryptographic applications, and such algorithms are called pseudo-random number generators, or PRNGs. A PRNG requires a small random input, called the seed, so it doesn't always produce the same output. From the seed, the PRNG produces a much larger string of acceptably random output; essentially, it is a randomness "stretcher." So a program using a PRNG still needs to find some good random bits, just fewer of them, but they had better be quite unpredictable.
Since various programs require random bits, some operating systems have built-in facilities for providing them. Some Unix variants (including Linux and OpenBSD) have a device driver, accessed through /dev/random and /dev/urandom, that provides random bits when opened and read as a file. These bits are derived by all sorts of methods, some quite clever. Correctly filtered timing measurements of disk accesses, for example, can represent the fluctuations due to air turbulence around the drive heads. Another technique is to look at the least significant bits of noise coming from an unused microphone port. And of course, they can track fluctuating events such as network packet arrival times, keyboard events, interrupts, etc.
SSH implementations make use of randomness, but the process is largely invisible to the
end user. Here's what happens under the hood. SSH1 and SSH2, for example, use a kernel-
based randomness source if it is available, along with their own sampling of (one hopes)
fluctuating system parameters, gleaned by running such programs such as ps or netstat. It
uses these sources to seed its PRNG, as well as to "stir in" more randomness every once in
a while. Since it can be expensive to gather randomness, SSH stores its pool of random bits
in a file between invocations of the program, as shown in the following table:
|
SSH1
|
SSH2
|
|
|
Server
|
/etc/ssh_random_seed
|
/etc/ssh2/random_seed
|
|
Client
|
~/.ssh/random_seed
|
~/.ssh2/random_seed
|
These files should be kept protected, since they contain sensitive information that can
weaken SSH's security if disclosed to an attacker, although SSH takes steps to reduce that
possibility. The seed information is always mixed with some new entropy before being
used, and only half the pool is ever saved to disk, to reduce its predictive value if stolen.
In SSH1 and SSH2, all this happens automatically and invisibly. When compiling OpenSSH on platform without /dev/random, you have a choice. If you have installed an add-on randomness source, such as the OpenSSH-recommended " Entropy Gathering Daemon" (EGD, http://www.lothar.com/tech/crypto/), you can tell OpenSSH to use it with
the switch -with-egd-pool. If you don't specify a pool, OpenSSH uses an internal entropy-gathering mechanism. You can tailor which programs are run to gather entropy and "how random" they're considered to be, by editing the file /etc/ssh_prng_cmds. Also, note that OpenSSH random seed is kept in the ~/.ssh/prng_seed file, even the daemon's, which is just the root user's seed file.
In SSH1 and SSH2, all this happens automatically and invisibly. When compiling OpenSSH on platform without /dev/random, you have a choice. If you have installed an add-on randomness source, such as the OpenSSH-recommended " Entropy Gathering Daemon" (EGD, http://www.lothar.com/tech/crypto/), you can tell OpenSSH to use it with
the switch -with-egd-pool. If you don't specify a pool, OpenSSH uses an internal entropy-gathering mechanism. You can tailor which programs are run to gather entropy and "how random" they're considered to be, by editing the file /etc/ssh_prng_cmds. Also, note that OpenSSH random seed is kept in the ~/.ssh/prng_seed file, even the daemon's, which is just the root user's seed file.
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 3. Inside SSH
3.8 SSH and File Transfers (scp and sftp)
The first thing to understand about SSH and file transfers, is that SSH doesn't do file transfers.
Ahem.
Now that we have your attention, what can we possibly mean by that? After all, there are entire sections of this book dedicated to explaining how to use scp1, scp2, and sftp for file transfers. What we mean is that there is nothing in the SSH protocol about transferring files: an SSH speaker can't ask its partner to send or receive a file through the protocol. And the programs we just mentioned don't actually implement the SSH protocol themselves nor incorporate any security features at all. Instead, they actually run the SSH client in a subprocess, in order to connect to the remote host and run the other half of the file-transfer process there. There is nothing very SSH-specific about these programs; they use SSH in much the same way as do other applications we cover, such as CVS and Pine.
The only reason it was necessary to come up with scp1 in the first place was that there was no widely used, general- purpose file-transfer protocol available that operated over a the single, full-duplex byte stream connection provided by the SSH remote program execution. If existing FTP implementations could easily be made to operate over SSH, there would be no need for ssh, but as we'll see, FTP is entirely unsuited to this. [Section 11.2] So Tatu Ylönen wrote scp1 and made it part of SSH1. The protocol it uses (let's call it "SCP1") remained entirely undocumented, even when Ylönen wrote the first RFC documenting the SSH-1 protocol.
Later, when SSH Communications Security was writing SSH2, they wanted to continue to include a file-transfer tool. They stayed with the model of layering it on top of SSH proper, but decided to entirely reimplement it. Thus, they replaced the "scp1 protocol" with the "SFTP protocol," as it is commonly known. The SFTP protocol is again simply a way to do bidirectional file transfers over a single, reliable, full-duplex byte stream connection. It happens to be based on the same packet protocol used as the substrate for the SSH Connection Protocol, presumably as a matter of convenience. The implementers already had a tool available for sending record-oriented messages over a byte pipe, so they reused it. SFTP remains an undocumented, proprietary protocol at press time, though there is work beginning in the IETF SECSH working group to document and standardize it.
The name SFTP is really unfortunate, because it confuses people on a number of levels. Most take it to stand for "Secure FTP." First, just as with scp1, as a protocol it isn't secure at all; the implementation derives its security by speaking the protocol over an SSH connection. And second, it has nothing whatsoever to do with the FTP protocol. It is a common mistake to think you can somehow use SFTP to talk securely to an FTP server-a reasonable enough supposition, given the name.
Another confusing aspect of file transfer in SSH2, is the relationship among the two programs scp2 and sftp, and the SFTP protocol. In SSH1, there is a single file-transfer protocol, SCP1, and a single program embodying it: scp1. In SSH2, there is also a single, new file-transfer protocol: SFTP. But there are three separate programs implementing it and two different clients. The server side is the program sftp-server. The two clients are scp2 and sftp. scp2 and sftp are simply two different front-ends for the same process: each runs the SSH2 client in a subprocess to start and speak to sftp-server on the remote host. They merely provide different user interfaces: scp2 is more like the traditional rcp, and sftp is deliberately similar to an FTP client.
None of this confusing terminology is made any easier by the fact that both SSH1 and SSH2 when installed make symbolic links allowing you to use the plain names "scp," "ssh," etc., instead of "scp1" or "ssh2." When we speak of the two SSH-related file-transfer protocols, we call them the SCP1 and SFTP protocols. SCP1 is sometimes also just called the "scp" protocol, which is technically ambiguous but usually understood. We suppose you could refer to SFTP
[21]
as the "scp2 protocol," but we've never heard it and don't recommend it if you want to keep your sanity.
3.8 SSH and File Transfers (scp and sftp)
The first thing to understand about SSH and file transfers, is that SSH doesn't do file transfers.
Ahem.
Now that we have your attention, what can we possibly mean by that? After all, there are entire sections of this book dedicated to explaining how to use scp1, scp2, and sftp for file transfers. What we mean is that there is nothing in the SSH protocol about transferring files: an SSH speaker can't ask its partner to send or receive a file through the protocol. And the programs we just mentioned don't actually implement the SSH protocol themselves nor incorporate any security features at all. Instead, they actually run the SSH client in a subprocess, in order to connect to the remote host and run the other half of the file-transfer process there. There is nothing very SSH-specific about these programs; they use SSH in much the same way as do other applications we cover, such as CVS and Pine.
The only reason it was necessary to come up with scp1 in the first place was that there was no widely used, general- purpose file-transfer protocol available that operated over a the single, full-duplex byte stream connection provided by the SSH remote program execution. If existing FTP implementations could easily be made to operate over SSH, there would be no need for ssh, but as we'll see, FTP is entirely unsuited to this. [Section 11.2] So Tatu Ylönen wrote scp1 and made it part of SSH1. The protocol it uses (let's call it "SCP1") remained entirely undocumented, even when Ylönen wrote the first RFC documenting the SSH-1 protocol.
Later, when SSH Communications Security was writing SSH2, they wanted to continue to include a file-transfer tool. They stayed with the model of layering it on top of SSH proper, but decided to entirely reimplement it. Thus, they replaced the "scp1 protocol" with the "SFTP protocol," as it is commonly known. The SFTP protocol is again simply a way to do bidirectional file transfers over a single, reliable, full-duplex byte stream connection. It happens to be based on the same packet protocol used as the substrate for the SSH Connection Protocol, presumably as a matter of convenience. The implementers already had a tool available for sending record-oriented messages over a byte pipe, so they reused it. SFTP remains an undocumented, proprietary protocol at press time, though there is work beginning in the IETF SECSH working group to document and standardize it.
The name SFTP is really unfortunate, because it confuses people on a number of levels. Most take it to stand for "Secure FTP." First, just as with scp1, as a protocol it isn't secure at all; the implementation derives its security by speaking the protocol over an SSH connection. And second, it has nothing whatsoever to do with the FTP protocol. It is a common mistake to think you can somehow use SFTP to talk securely to an FTP server-a reasonable enough supposition, given the name.
Another confusing aspect of file transfer in SSH2, is the relationship among the two programs scp2 and sftp, and the SFTP protocol. In SSH1, there is a single file-transfer protocol, SCP1, and a single program embodying it: scp1. In SSH2, there is also a single, new file-transfer protocol: SFTP. But there are three separate programs implementing it and two different clients. The server side is the program sftp-server. The two clients are scp2 and sftp. scp2 and sftp are simply two different front-ends for the same process: each runs the SSH2 client in a subprocess to start and speak to sftp-server on the remote host. They merely provide different user interfaces: scp2 is more like the traditional rcp, and sftp is deliberately similar to an FTP client.
None of this confusing terminology is made any easier by the fact that both SSH1 and SSH2 when installed make symbolic links allowing you to use the plain names "scp," "ssh," etc., instead of "scp1" or "ssh2." When we speak of the two SSH-related file-transfer protocols, we call them the SCP1 and SFTP protocols. SCP1 is sometimes also just called the "scp" protocol, which is technically ambiguous but usually understood. We suppose you could refer to SFTP
[21]
as the "scp2 protocol," but we've never heard it and don't recommend it if you want to keep your sanity.
3.8.1 scp1 Details
When you run scp1 to copy a file from client to server, it invokes ssh1 like this:
ssh -x -a -o "FallBackToRsh no" -o "ClearAllForwardings yes" server-host scp ...
This runs another copy of scp on the remote host. That copy is invoked with the undocumented switches -t and -f (for "to" and "from"), putting it into SCP1 server mode. This next table shows some examples; Figure 3-6 shows the details.
ssh -x -a -o "FallBackToRsh no" -o "ClearAllForwardings yes" server-host scp ...
This runs another copy of scp on the remote host. That copy is invoked with the undocumented switches -t and -f (for "to" and "from"), putting it into SCP1 server mode. This next table shows some examples; Figure 3-6 shows the details.
|
This client scp command:
|
Runs this remote command:
|
scp foo server:bar
|
scp -t bar
|
scp server:bar foo
|
scp -f bar
|
scp *.txt server:dir
|
scp -d -t dir
|
Figure 3.6. scp1 operation
If you run scp1 to copy a file between two remote hosts, it simply executes another scp1 client on the source host to copy the file to the target. For example, this command:
ssh1 -x -a ... as above ... source scp1 music.au target:playme 3.8.2 scp2/sftp Details
When you run scp2 or sftp, they run ssh2 behind the scenes, using this command:
If you run scp1 to copy a file between two remote hosts, it simply executes another scp1 client on the source host to copy the file to the target. For example, this command:
scp1 source:music.au target:playme
runs this in the background:
ssh1 -x -a ... as above ... source scp1 music.au target:playme 3.8.2 scp2/sftp Details
When you run scp2 or sftp, they run ssh2 behind the scenes, using this command:
ssh2 -x -a -o passwordprompt "%U@%H\'s password:"
-o "nodelay yes"
-o "authenticationnotify yes"
server host
-s sftp
Unlike scp1, here the command doesn't vary depending on the direction or type of file transfer; all the necessary information is carried inside the SFTP protocol.
Note that they don't start sftp-server with a remote command, but rather with the SSH2 "subsystem" mechanism via the -s sftp option. [Section 5.7] This means that the SSH2 server must be configured to handle this subsystem, with a line like this in /etc/sshd2_config:
subsystem-sftp /usr/local/sbin/sftp-server
Assuming the ssh2 command succeeds, sftp and sftp-server start speaking the SFTP protocol over the SSH session, and
the user can send and retrieve files. Figure 3-7 shows the details.
Figure 3.7. scp2/sftp operation
Our testing shows roughly a factor-of-four reduction in throughput from scp1 to scp2. We observe that the SFTP mechanism uses the SSH packet protocol twice, one encapsulated inside the other: the SFTP protocol itself uses the packet protocol as its basis, and that runs on top of an SSH session. While this is certainly inefficient, it seems unlikely to be the reason for such a dramatic reduction in performance; perhaps there are simply implementation problems that can be fixed, such as bad interactions between buffering in different layers of the protocol code. We have not dug into the code ourselves to find a reason for the slowdown.
[21]
Especially since scp2 may run scp1 for SSH1 compatibility! Oy gevalt!
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 3. Inside SSH
3.9 Algorithms Used by SSH
Table 3-4 through Table 3-6 summarize the available ciphers in the SSH protocols and
their implementations. Required algorithms are in bold;, recommended ones are italic; the others are optional. Parentheses indicate an algorithm not defined in the protocol, but provided in some implementation. The meanings of the entries are:
3.9 Algorithms Used by SSH
Table 3-4 through Table 3-6 summarize the available ciphers in the SSH protocols and
their implementations. Required algorithms are in bold;, recommended ones are italic; the others are optional. Parentheses indicate an algorithm not defined in the protocol, but provided in some implementation. The meanings of the entries are:
x
o
-
o
-
The implementation supports the algorithm and is included in the default build.
The implementation supports the algorithm, but it isn't included in the default build (it must be specifically enabled when compiling).
The implementation doesn't support the algorithm.
Table 3.4. Algorithms in the SSH Protocols
The implementation supports the algorithm, but it isn't included in the default build (it must be specifically enabled when compiling).
The implementation doesn't support the algorithm.
Table 3.4. Algorithms in the SSH Protocols
|
SSH-1.5
|
SSH-2.0
|
|
|
Public-key
|
RSA
|
DSA, DH
|
|
Hash
|
MD5, CRC-32
|
SHA-1, MD5
|
|
Symmetric
|
3DES, IDEA, ARCFOUR, DES
|
3DES, Blowfish, Twofish, CAST-128,
IDEA, ARCFOUR
|
|
Compression
|
zlib
|
zlib
|
Note that Table 3-4 simply lists algorithms in different categories used in the two protocol
specifications, without regard to purpose. So for example, SSH-1 uses both MD5 and CRC- 32, but for different purposes; this listing doesn't imply that SSH-1 has option to employ
specifications, without regard to purpose. So for example, SSH-1 uses both MD5 and CRC- 32, but for different purposes; this listing doesn't imply that SSH-1 has option to employ
MD5 for integrity checking.
Table 3.5. SSH-1 Ciphers
|
3DES
|
IDEA
|
RC4
|
DES
|
(Blowfish)
|
|
|
SSH1
|
x
|
x
|
o
|
o
|
x
|
|
OpenSSH
|
x
|
-
|
-
|
-
|
x
|
Table 3.6. SSH-2 Ciphers
|
3DES
|
Blowfish
|
Twofish
|
CAST-128
|
IDEA
|
RC4
|
|
|
SSH2
|
x
|
x
|
x
|
-
|
-
|
x
|
|
F-Secure SSH2
|
x
|
x
|
x
|
x
|
-
|
x
|
|
OpenSSH
|
x
|
x
|
-
|
x
|
-
|
x
|
Why are some algorithms unsupported by different programs? DES is often omitted from
SSH-1 software as insufficiently secure. RC4 is omitted because of problems in the way it
is used in the SSH-1 protocol, permitting vulnerabilities to active network-level attacks;
this problem has been fixed in SSH-2. IDEA is omitted from OpenSSH and the
noncommercial SSH1 and SSH2 because it is patented and requires royalties for
commercial use. Twofish isn't in OpenSSH because it isn't yet part of the OpenSSL toolkit,
which OpenSSH uses. CAST-128 is free, so we don't know why it is missing from the
noncommercial SSH2.
The free version of SSH2 supports only the required DSA for public keys, while the commercial F-Secure SSH2 Server adds partial support for RSA keys for user authentication. [Section 6.2.2]. The F-Secure server starts if its host key is RSA and reports
that it successfully read the key. However, it still advertises its host key type as DSA in its key-exchange messages and then supplies the RSA key anyway, causing clients to fail
The free version of SSH2 supports only the required DSA for public keys, while the commercial F-Secure SSH2 Server adds partial support for RSA keys for user authentication. [Section 6.2.2]. The F-Secure server starts if its host key is RSA and reports
that it successfully read the key. However, it still advertises its host key type as DSA in its key-exchange messages and then supplies the RSA key anyway, causing clients to fail
when they try to read the supplied key. Of course, this problem masks the question of
whether the client can handle an RSA host key even if it were properly identified.
OpenSSH/2 doesn't contain RSA support at all, but now that the RSA patent has expired,
the ssh-rsa key type will be added to the SSH-2 protocol, and support should follow shortly.
We now summarize each of the algorithms we have mentioned. Don't treat these summaries as complete analyses, however. You can't necessarily extrapolate from characteristics of individual algorithms (positive or negative) to whole systems without considering the other parts. Security is complicated that way.
3.9.1 Public-Key Algorithms
3.9.1.1 Rivest-Shamir-Adleman (RSA)
The Rivest-Shamir-Adleman public-key algorithm (RSA) is the most widely used asymmetric cipher. It derives its security from the difficulty of factoring large integers that are the product of two large primes of roughly equal size. Factoring is widely believed to be intractable (i.e., infeasible, admitting no efficient, polynomial-time solution), although this isn't proven. RSA can be used for both encryption and signatures.
Until September 2000, RSA was claimed to be patented in the United States by Public Key Partners, Inc., a company in which RSA Security, Inc. is a partner. (The algorithm is now in the public domain.) While the patent was in force, PKP claimed that it controlled the use of the RSA algorithm in the USA, and that the use of unauthorized implementations was illegal. Until the mid-1990s, RSA Security provided a freely available reference implementation, RSAref, with a license allowing educational and broad commercial use (as long as the software itself was not sold for profit). They no longer support or distribute this toolkit, though it is commonly available. Since RSA is now in the public domain, there's no longer any reason to use RSAref. It is no longer supported, some versions contain security flaws, and there are better implementations out there; we discourage its use.
The SSH-1 protocol specifies use of RSA explicitly. SSH-2 can use multiple public-key algorithms, but it defines only DSA. [Section 3.9.1.2] The SECSH working group plans to
add the RSA algorithm to SSH-2 now that the patent has expired. In the meantime, only the F-Secure SSH2 Server implements RSA keys in SSH2, using the global key-format identifier "ssh-rsa". This isn't yet part of the draft standard: to be technically correct it should use a localized name, e.g., ssh-rsa@datafellows.com. [Section 3.5.1.1] However,
this is unlikely to cause a real problem. The feature is useful for authentication to an SSH2 server with an existing SSH1 key, so you don't need to generate a new (DSA) key.
3.9.1.2 Digital Signature Algorithm (DSA)
The Digital Signature Algorithm (DSA) was developed by the U.S. National Security Agency (NSA), and promulgated by the U.S. National Institute of Standards and
We now summarize each of the algorithms we have mentioned. Don't treat these summaries as complete analyses, however. You can't necessarily extrapolate from characteristics of individual algorithms (positive or negative) to whole systems without considering the other parts. Security is complicated that way.
3.9.1 Public-Key Algorithms
3.9.1.1 Rivest-Shamir-Adleman (RSA)
The Rivest-Shamir-Adleman public-key algorithm (RSA) is the most widely used asymmetric cipher. It derives its security from the difficulty of factoring large integers that are the product of two large primes of roughly equal size. Factoring is widely believed to be intractable (i.e., infeasible, admitting no efficient, polynomial-time solution), although this isn't proven. RSA can be used for both encryption and signatures.
Until September 2000, RSA was claimed to be patented in the United States by Public Key Partners, Inc., a company in which RSA Security, Inc. is a partner. (The algorithm is now in the public domain.) While the patent was in force, PKP claimed that it controlled the use of the RSA algorithm in the USA, and that the use of unauthorized implementations was illegal. Until the mid-1990s, RSA Security provided a freely available reference implementation, RSAref, with a license allowing educational and broad commercial use (as long as the software itself was not sold for profit). They no longer support or distribute this toolkit, though it is commonly available. Since RSA is now in the public domain, there's no longer any reason to use RSAref. It is no longer supported, some versions contain security flaws, and there are better implementations out there; we discourage its use.
The SSH-1 protocol specifies use of RSA explicitly. SSH-2 can use multiple public-key algorithms, but it defines only DSA. [Section 3.9.1.2] The SECSH working group plans to
add the RSA algorithm to SSH-2 now that the patent has expired. In the meantime, only the F-Secure SSH2 Server implements RSA keys in SSH2, using the global key-format identifier "ssh-rsa". This isn't yet part of the draft standard: to be technically correct it should use a localized name, e.g., ssh-rsa@datafellows.com. [Section 3.5.1.1] However,
this is unlikely to cause a real problem. The feature is useful for authentication to an SSH2 server with an existing SSH1 key, so you don't need to generate a new (DSA) key.
3.9.1.2 Digital Signature Algorithm (DSA)
The Digital Signature Algorithm (DSA) was developed by the U.S. National Security Agency (NSA), and promulgated by the U.S. National Institute of Standards and
Technology (NIST) as part of the Digital Signature Standard ( DSS). The DSS was issued
as a Federal Information Processing Standard, FIPS-186, in May 1994. It is a public-key
algorithm, based on the Schnorr and ElGamal methods, and relies on the difficulty of
computing discrete logarithms in a finite field. It is designed as a signature-only scheme
that can't be used for encryption, although a fully general implementation may easily
perform both RSA and ElGamal encryption.
DSA has also been surrounded by a swirl of controversy since its inception. The NIST first claimed that it had designed DSA, then eventually revealed that the NSA had done so. Many question the motives and ethics of the NSA, with ample historical reason to do so. [22]
Researcher Gus Simmons discovered a subliminal channel in DSA that allows an
[23]
implementor to leak information-for instance, secret key bits-with every signature.
Since the algorithm was to be made available as a closed hardware implementation in smart cards as part of the government's Capstone program, many people considered this property highly suspicious. Finally, NIST intended DSA to be available royalty-free to all users. To that end it was patented by David Kravitz (patent #5,231,668), then an employee of the NSA, who assigned the patent to the U.S. government. There have been claims, however, that DSA infringes existing cryptographic patents, including the Schnorr patent. To our knowledge, this issue has yet to be settled in court.
The SSH-2 protocol uses DSA as its required (and currently, only defined) public-key algorithm for host identification.
3.9.1.3 Diffie-Hellman key agreement
The Diffie-Hellman key agreement algorithm was the original public-key system, invented by Whitfield Diffie, Martin Hellman, and Ralph Merkle in 1976. It was patented by them in 1977 (issued in 1980, patent #4,200,770); that patent has now expired, and the algorithm is in the public domain. Like DSA, it is based on the discrete logarithm problem, and it allows two parties to derive a shared secret key securely over an open channel. That is, the parties engage in an exchange of messages, at the end of which they share a secret key. It isn't feasible for an eavesdropper to determine the shared secret merely from observing the exchanged messages.
SSH-2 uses the Diffie-Hellman algorithm as its required (and currently, its only defined) key-exchange method.
3.9.2 Secret-Key Algorithms
3.9.2.1 International Data Encryption Algorithm (IDEA)
The International Data Encryption Algorithm (IDEA) was designed in 1990 by Xuejia Lai
[24]
and James Massey, and went through several revisions, improvements, and renamings before reaching its current form. Although relatively new, it is considered secure; the well-
DSA has also been surrounded by a swirl of controversy since its inception. The NIST first claimed that it had designed DSA, then eventually revealed that the NSA had done so. Many question the motives and ethics of the NSA, with ample historical reason to do so. [22]
Researcher Gus Simmons discovered a subliminal channel in DSA that allows an
[23]
implementor to leak information-for instance, secret key bits-with every signature.
Since the algorithm was to be made available as a closed hardware implementation in smart cards as part of the government's Capstone program, many people considered this property highly suspicious. Finally, NIST intended DSA to be available royalty-free to all users. To that end it was patented by David Kravitz (patent #5,231,668), then an employee of the NSA, who assigned the patent to the U.S. government. There have been claims, however, that DSA infringes existing cryptographic patents, including the Schnorr patent. To our knowledge, this issue has yet to be settled in court.
The SSH-2 protocol uses DSA as its required (and currently, only defined) public-key algorithm for host identification.
3.9.1.3 Diffie-Hellman key agreement
The Diffie-Hellman key agreement algorithm was the original public-key system, invented by Whitfield Diffie, Martin Hellman, and Ralph Merkle in 1976. It was patented by them in 1977 (issued in 1980, patent #4,200,770); that patent has now expired, and the algorithm is in the public domain. Like DSA, it is based on the discrete logarithm problem, and it allows two parties to derive a shared secret key securely over an open channel. That is, the parties engage in an exchange of messages, at the end of which they share a secret key. It isn't feasible for an eavesdropper to determine the shared secret merely from observing the exchanged messages.
SSH-2 uses the Diffie-Hellman algorithm as its required (and currently, its only defined) key-exchange method.
3.9.2 Secret-Key Algorithms
3.9.2.1 International Data Encryption Algorithm (IDEA)
The International Data Encryption Algorithm (IDEA) was designed in 1990 by Xuejia Lai
[24]
and James Massey, and went through several revisions, improvements, and renamings before reaching its current form. Although relatively new, it is considered secure; the well-
known cryptographer Bruce Schneier in 1996 pronounced it "the best and most secure
block algorithm available to the public at this time."
IDEA is patented in Europe and the United States by the Swiss company Ascom-Tech AG.
[25]
The name "IDEA" is a trademark of Ascom-Tech. The attitude of Ascom-Tech towards this patent and the use of IDEA in the United States has changed over time, especially with regard to its inclusion in PGP. It is free for noncommercial use. Government or commercial use may require a royalty, where "commercial use" includes use of the algorithm internal to a commercial organization, not just directly selling an implementation or offering its use for profit. Here are two sites for more information:
http://www.ascom.ch/infosec/idea.html http://www.it-sec.com/index_e.php
3.9.2.2 Data Encryption Standard (DES)
The Data Encryption Standard (DES) is the aging workhorse of symmetric encryption algorithms. Designed by researchers at IBM in the early 1970s under the name Lucifer, the U.S. government adopted DES as a standard on November 23, 1976 (FIPS-46). It was patented by IBM, but IBM granted free worldwide rights to its use. It has been used extensively in the public and private sectors ever since. DES has stood up well to cryptanalysis over the years and is becoming viewed as outdated only because its 56-bit key size is too small relative to modern computing power. A number of well-publicized designs for special-purpose "DES-cracking" machines have been put forward, and their putative prices are falling more and more into the realm of plausibility for governments and large companies. It seems sure that at least the NSA has such devices. Because of these weaknesses, NIST is currently in the process of selecting a successor to DES, called the Advanced Encryption Standard (AES).
3.9.2.3 Triple-DES
Triple-DES, or 3DES, is a variant of DES intended to increase its security by increasing the
[26]
key length. It has been proven that the DES function doesn't form a group over its keys, which means that encrypting multiple times with independent keys can increase security. 3DES encrypts the plaintext with three iterations of the DES algorithm, using three separate keys. The effective key length of 3DES is 112 bits, a vast improvement over the 56-bit key of plain DES.
3.9.2.4 ARCFOUR (RC4)
Ron Rivest designed the RC4 cipher in 1987 for RSA Data Security, Inc. (RSADSI); the name is variously claimed to stand for "Rivest Cipher" or "Ron's Code." It was an unpatented trade secret of RSADSI, used in quite a number of commercial products by RSADSI licensees. In 1994, though, source code claiming to implement RC4 appeared
IDEA is patented in Europe and the United States by the Swiss company Ascom-Tech AG.
[25]
The name "IDEA" is a trademark of Ascom-Tech. The attitude of Ascom-Tech towards this patent and the use of IDEA in the United States has changed over time, especially with regard to its inclusion in PGP. It is free for noncommercial use. Government or commercial use may require a royalty, where "commercial use" includes use of the algorithm internal to a commercial organization, not just directly selling an implementation or offering its use for profit. Here are two sites for more information:
http://www.ascom.ch/infosec/idea.html http://www.it-sec.com/index_e.php
3.9.2.2 Data Encryption Standard (DES)
The Data Encryption Standard (DES) is the aging workhorse of symmetric encryption algorithms. Designed by researchers at IBM in the early 1970s under the name Lucifer, the U.S. government adopted DES as a standard on November 23, 1976 (FIPS-46). It was patented by IBM, but IBM granted free worldwide rights to its use. It has been used extensively in the public and private sectors ever since. DES has stood up well to cryptanalysis over the years and is becoming viewed as outdated only because its 56-bit key size is too small relative to modern computing power. A number of well-publicized designs for special-purpose "DES-cracking" machines have been put forward, and their putative prices are falling more and more into the realm of plausibility for governments and large companies. It seems sure that at least the NSA has such devices. Because of these weaknesses, NIST is currently in the process of selecting a successor to DES, called the Advanced Encryption Standard (AES).
3.9.2.3 Triple-DES
Triple-DES, or 3DES, is a variant of DES intended to increase its security by increasing the
[26]
key length. It has been proven that the DES function doesn't form a group over its keys, which means that encrypting multiple times with independent keys can increase security. 3DES encrypts the plaintext with three iterations of the DES algorithm, using three separate keys. The effective key length of 3DES is 112 bits, a vast improvement over the 56-bit key of plain DES.
3.9.2.4 ARCFOUR (RC4)
Ron Rivest designed the RC4 cipher in 1987 for RSA Data Security, Inc. (RSADSI); the name is variously claimed to stand for "Rivest Cipher" or "Ron's Code." It was an unpatented trade secret of RSADSI, used in quite a number of commercial products by RSADSI licensees. In 1994, though, source code claiming to implement RC4 appeared
anonymously on the Internet. Experimentation quickly confirmed that the posted code was
indeed compatible with RC4, and the cat was out of the bag. Since it had never been
patented, RC4 effectively entered the public domain. This doesn't mean that RSADSI won't
sue someone who tries to use it in a commercial product, so it is less expensive to settle and
license than to fight. We aren't aware of any test cases of this issue. Since the name "RC4"
is trademarked by RSADSI, the name "ARCFOUR" has been coined to refer to the
publicly revealed version of the algorithm.
ARCFOUR is very fast but less studied than many other algorithms. It uses a variable-sized key; SSH-1 employs independent 128-bits keys for each direction of the SSH session. The use of independent keys for each direction is an exception in SSH-1, and crucial: ARCFOUR is essentially a pad using the output of a pseudo-random number generator. As such, it is important never to reuse a key because to do so makes cryptanalysis trivially easy. If this caveat is observed, ARCFOUR is considered secure by many, despite the dearth of public cryptanalytic results.
3.9.2.5 Blowfish
Blowfish was designed by Bruce Schneier in 1993, as a step toward replacing the aging DES. It is much faster than DES and IDEA, though not as fast as ARCFOUR, and is unpatented and free for all uses. It is intended specifically for implementation on large, modern, general-purpose microprocessors and for situations with relatively few key changes. It isn't particularly suited to low-end environments such as smart cards. It employs a variable-sized key of 32 to 448 bits; SSH-2 uses 128-bit keys. Blowfish has received a fair amount of cryptanalytic scrutiny and has proved impervious to attack so far. Information is available from Counterpane, Schneier's security consulting company, at:
http://www.counterpane.com/blowfish.html
3.9.2.6 Twofish
Twofish is another design by Bruce Schneier, together with J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson. It was submitted in 1998 to the NIST as a candidate for the Advanced Encryption Standard, to replace DES as the U.S. government's symmetric data encryption standard. Two years later, it is one of the five finalists in the AES selection process, out of 15 initial submissions. Like Blowfish, it is unpatented and free for all uses, and Counterpane has provided uncopyrighted reference implementations, also freely usable.
Twofish admits keys of lengths 128, 192, or 256 bits; SSH-2 specifies 256-bit keys. Twofish is designed to be more flexible than Blowfish, allowing good implementation in a larger variety of computing environments (e.g., slower processors, small memory, in- hardware). It is very fast, its design is conservative, and it is likely to be quite strong. You can read more about Twofish at:
ARCFOUR is very fast but less studied than many other algorithms. It uses a variable-sized key; SSH-1 employs independent 128-bits keys for each direction of the SSH session. The use of independent keys for each direction is an exception in SSH-1, and crucial: ARCFOUR is essentially a pad using the output of a pseudo-random number generator. As such, it is important never to reuse a key because to do so makes cryptanalysis trivially easy. If this caveat is observed, ARCFOUR is considered secure by many, despite the dearth of public cryptanalytic results.
3.9.2.5 Blowfish
Blowfish was designed by Bruce Schneier in 1993, as a step toward replacing the aging DES. It is much faster than DES and IDEA, though not as fast as ARCFOUR, and is unpatented and free for all uses. It is intended specifically for implementation on large, modern, general-purpose microprocessors and for situations with relatively few key changes. It isn't particularly suited to low-end environments such as smart cards. It employs a variable-sized key of 32 to 448 bits; SSH-2 uses 128-bit keys. Blowfish has received a fair amount of cryptanalytic scrutiny and has proved impervious to attack so far. Information is available from Counterpane, Schneier's security consulting company, at:
http://www.counterpane.com/blowfish.html
3.9.2.6 Twofish
Twofish is another design by Bruce Schneier, together with J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson. It was submitted in 1998 to the NIST as a candidate for the Advanced Encryption Standard, to replace DES as the U.S. government's symmetric data encryption standard. Two years later, it is one of the five finalists in the AES selection process, out of 15 initial submissions. Like Blowfish, it is unpatented and free for all uses, and Counterpane has provided uncopyrighted reference implementations, also freely usable.
Twofish admits keys of lengths 128, 192, or 256 bits; SSH-2 specifies 256-bit keys. Twofish is designed to be more flexible than Blowfish, allowing good implementation in a larger variety of computing environments (e.g., slower processors, small memory, in- hardware). It is very fast, its design is conservative, and it is likely to be quite strong. You can read more about Twofish at:
http://www.counterpane.com/twofish.html
You can read more about the NIST AES program at:
http://www.nist.gov/aes/
3.9.2.7 CAST
CAST was designed in the early 1990s by Carlisle Adams and Stafford Tavares. Tavares is on the faculty of Queen's University at Kingston in Canada, while Adams is an employee of Entrust Technologies of Texas. CAST is patented, and the rights are held by Entrust, which has made two versions of the algorithm available on a worldwide royalty-free basis for all uses. These versions are CAST-128 and CAST-256, described in RFC-2144 and RFC-2612, respectively. SSH-2 uses CAST-128, which is named for its 128-bit key length.
3.9.2.8 Speed comparisons
We ran some simple experiments to rank the bulk ciphers in order of speed. Since there is no single SSH package that contains all of the ciphers, we present two experiments to cover them all. Table 3-7 and Table 3-8 show the time required to transfer a 5-MB file
from a 300-MHz Linux box to a 100-MHz Sparc-20 over an otherwise unloaded 10-base-T Ethernet.
Table 3.7. Transferring with scp2 (F-Secure SSH2 2.0.13)
http://www.nist.gov/aes/
3.9.2.7 CAST
CAST was designed in the early 1990s by Carlisle Adams and Stafford Tavares. Tavares is on the faculty of Queen's University at Kingston in Canada, while Adams is an employee of Entrust Technologies of Texas. CAST is patented, and the rights are held by Entrust, which has made two versions of the algorithm available on a worldwide royalty-free basis for all uses. These versions are CAST-128 and CAST-256, described in RFC-2144 and RFC-2612, respectively. SSH-2 uses CAST-128, which is named for its 128-bit key length.
3.9.2.8 Speed comparisons
We ran some simple experiments to rank the bulk ciphers in order of speed. Since there is no single SSH package that contains all of the ciphers, we present two experiments to cover them all. Table 3-7 and Table 3-8 show the time required to transfer a 5-MB file
from a 300-MHz Linux box to a 100-MHz Sparc-20 over an otherwise unloaded 10-base-T Ethernet.
Table 3.7. Transferring with scp2 (F-Secure SSH2 2.0.13)
|
Cipher
|
Transfer Time (seconds)
|
Throughput (KB/second)
|
|
RC4
|
22.5
|
227.4
|
|
Blowfish
|
24.5
|
208.6
|
|
CAST-128
|
26.4
|
193.9
|
|
Twofish
|
28.2
|
181.3
|
|
3DES
|
51.8
|
98.8
|
Table 3.8. Same Test with scp1 (SSH-1.2.27)
|
Cipher
|
Transfer Time (seconds)
|
Throughput (KB/second)
|
|
RC4
|
5
|
1024.0
|
|
Blowfish
|
6
|
853.3
|
|
CAST-128
|
7
|
731.4
|
|
Twofish
|
14
|
365.7
|
|
3DES
|
15
|
341.3
|
This is necessarily a gross comparison, and we provide it only as a rough guideline.
Remember that these numbers reflect the performance of particular implementations, not
the algorithms themselves, tested in a single configuration. Your mileage may vary.
Objects in mirror are closer than they appear.
Note that scp1 is roughly four times faster than scp2. This is due to a major implementation difference: scp1 uses the scp1 -t server, whereas scp2 uses the SFTP subsystem. [Section
7.5.9] Nonetheless, the relative cipher speed comparisons do agree where they overlap.
We must emphasize that we included RC4 in the SSH1 test only for completeness; due to security vulnerabilities, RC4 shouldn't ordinarily be used with the SSH-1 protocol.
3.9.3 Hash Functions 3.9.3.1 CRC-32
[27]
The 32-bit Cyclic Redundancy Check (CRC-32), defined in ISO 3309, is a noncryptographic hash function for detecting accidental changes to data. The SSH-1 protocol uses CRC-32 (with the polynomial 0xEDB88320) for integrity checking, and this weakness admits the "insertion attack" discussed later. [Section 3.10.5] The SSH-2
protocol employs cryptographically strong hash functions for integrity checking, obviating this attack.
Note that scp1 is roughly four times faster than scp2. This is due to a major implementation difference: scp1 uses the scp1 -t server, whereas scp2 uses the SFTP subsystem. [Section
7.5.9] Nonetheless, the relative cipher speed comparisons do agree where they overlap.
We must emphasize that we included RC4 in the SSH1 test only for completeness; due to security vulnerabilities, RC4 shouldn't ordinarily be used with the SSH-1 protocol.
3.9.3 Hash Functions 3.9.3.1 CRC-32
[27]
The 32-bit Cyclic Redundancy Check (CRC-32), defined in ISO 3309, is a noncryptographic hash function for detecting accidental changes to data. The SSH-1 protocol uses CRC-32 (with the polynomial 0xEDB88320) for integrity checking, and this weakness admits the "insertion attack" discussed later. [Section 3.10.5] The SSH-2
protocol employs cryptographically strong hash functions for integrity checking, obviating this attack.
3.9.3.2 MD5
MD5 ("Message Digest algorithm number 5") is a cryptographically strong, 128-bit hash
algorithm designed by Ron Rivest in 1991, one of a series he designed for RSADSI (MD2
through MD5). MD5 is unpatented, placed in the public domain by RSADSI, and
documented in RFC-1321. It has been a standard hash algorithm for several years, used in
many cryptographic products and standards. A successful collision attack against the MD5
compression function by den Boer and Bosselaers in 1993 caused some concern, and
though the attack hasn't resulted in any practical weaknesses, there is an expectation that it
will, and people are beginning to avoid MD5 in favor of newer algorithms. RSADSI
themselves recommend moving away from MD5 in favor of SHA-1 or RIPEMD-160 for
[28]
future applications demanding collision-resistance.
3.9.3.3 SHA-1
SHA-1 (Secure Hash Algorithm) was designed by the NSA and NIST for use with the U.S. government Digital Signature Standard. Like MD5, it was designed as an improvement on MD4, but takes a different approach. It produces 160-bit hashes. There are no known attacks against SHA-1, and, if secure, it is stronger than MD5 simply for its longer hash value. It is starting to replace MD5 in some applications; for example, SSH-2 uses SHA-1 as its required MAC hash function, as opposed to MD5 in SSH-1.
3.9.3.4 RIPEMD-160
Yet another 160-bit MD4 variant, RIPEMD-160, was developed by Hans Dobbertin, Antoon Bosselaers, and Bart Preneel as part of the European Community RIPE project.
[29]
RIPE stands for RACE Integrity Primitives Evaluation; RACE, in turn, was the program for Research and Development in Advanced Communications Technologies in Europe, an EC-sponsored program which ran from June 1987 to December 1995 (http://
www.analysys.com). RIPE was part of the RACE effort, devoted to studying and
developing data integrity techniques. Hence, RIPEMD-160 should be read as "the RIPE Message Digest (160 bits)." In particular, it has nothing to do with RIPEM, an old Privacy- Enhanced Mail (PEM) implementation by Mark Riordan (http://ripem.msu.edu/ ).
RIPEMD-160 isn't defined in the SSH protocol, but it is used for an implementation- specific MAC algorithm in OpenSSH, under the name hmac-ripemd160@openssh. com. RIPEMD-160 is unpatented and free for all uses. You can read more about it at:
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
3.9.4 Compression Algorithms: zlib
[28]
future applications demanding collision-resistance.
3.9.3.3 SHA-1
SHA-1 (Secure Hash Algorithm) was designed by the NSA and NIST for use with the U.S. government Digital Signature Standard. Like MD5, it was designed as an improvement on MD4, but takes a different approach. It produces 160-bit hashes. There are no known attacks against SHA-1, and, if secure, it is stronger than MD5 simply for its longer hash value. It is starting to replace MD5 in some applications; for example, SSH-2 uses SHA-1 as its required MAC hash function, as opposed to MD5 in SSH-1.
3.9.3.4 RIPEMD-160
Yet another 160-bit MD4 variant, RIPEMD-160, was developed by Hans Dobbertin, Antoon Bosselaers, and Bart Preneel as part of the European Community RIPE project.
[29]
RIPE stands for RACE Integrity Primitives Evaluation; RACE, in turn, was the program for Research and Development in Advanced Communications Technologies in Europe, an EC-sponsored program which ran from June 1987 to December 1995 (http://
www.analysys.com). RIPE was part of the RACE effort, devoted to studying and
developing data integrity techniques. Hence, RIPEMD-160 should be read as "the RIPE Message Digest (160 bits)." In particular, it has nothing to do with RIPEM, an old Privacy- Enhanced Mail (PEM) implementation by Mark Riordan (http://ripem.msu.edu/ ).
RIPEMD-160 isn't defined in the SSH protocol, but it is used for an implementation- specific MAC algorithm in OpenSSH, under the name hmac-ripemd160@openssh. com. RIPEMD-160 is unpatented and free for all uses. You can read more about it at:
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
3.9.4 Compression Algorithms: zlib
zlib is currently the only compression algorithm defined for SSH. In the SSH protocol
documents, the term "zlib" refers to the "deflate" lossless compression algorithm as first
implemented in the popular gzip compression utility, and later documented in RFC-1951. It
is available as a software library called ZLIB at:
http://www.info-zip.org/pub/infozip/zlib/
[22]
See James Bamford's book, The Puzzle Palace (Penguin), for an investigative history of the
NSA.
[23]
G. J. Simmons, "The Subliminal Channels in the U.S. Digital Signature Algorithm (DSA)."
Proceedings of the Third Symposium on: State and Progress of Research in Cryptography, Rome: Fondazione Ugo Bordoni, 1993, pp. 35-54.
[24]
X. Lai and J. Massey, "A Proposal for a New Block Encryption Standard," Advances in
Cryptology-EUROCRYPT `92 Proceedings, Springer-Verlag, 1992, pp 389-404.
[25]
U.S. patent #5,214,703, 25 May 1993; international patent PCT/CH91/00117, 28 November
1991; European patent EP 482 154 B1.
[26]
K. W. Campbell and M. J. Wiener, "DES Is Not a Group," Advances in Cryptology-CRYPTO
`92 Proceedings, Springer-Verlag, pp. 512-520.
[27]
International Organization for Standardization, ISO Information Processing Systems-Data
Communication High-Level Data Link Control Procedure-Frame Structure, IS 3309, October 1984, 3rd Edition.
[28]
RSA Laboratories Bulletin #4, 12 November 1996, ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.
pdf.
[29]
Not to be confused with another "RIPE," Réseaux IP Européens ("European IP Networks"), a
technical and coordinating association of entities operating wide area IP networks in Europe and elsewhere (http://www.ripe.net).
http://www.info-zip.org/pub/infozip/zlib/
[22]
See James Bamford's book, The Puzzle Palace (Penguin), for an investigative history of the
NSA.
[23]
G. J. Simmons, "The Subliminal Channels in the U.S. Digital Signature Algorithm (DSA)."
Proceedings of the Third Symposium on: State and Progress of Research in Cryptography, Rome: Fondazione Ugo Bordoni, 1993, pp. 35-54.
[24]
X. Lai and J. Massey, "A Proposal for a New Block Encryption Standard," Advances in
Cryptology-EUROCRYPT `92 Proceedings, Springer-Verlag, 1992, pp 389-404.
[25]
U.S. patent #5,214,703, 25 May 1993; international patent PCT/CH91/00117, 28 November
1991; European patent EP 482 154 B1.
[26]
K. W. Campbell and M. J. Wiener, "DES Is Not a Group," Advances in Cryptology-CRYPTO
`92 Proceedings, Springer-Verlag, pp. 512-520.
[27]
International Organization for Standardization, ISO Information Processing Systems-Data
Communication High-Level Data Link Control Procedure-Frame Structure, IS 3309, October 1984, 3rd Edition.
[28]
RSA Laboratories Bulletin #4, 12 November 1996, ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.
pdf.
[29]
Not to be confused with another "RIPE," Réseaux IP Européens ("European IP Networks"), a
technical and coordinating association of entities operating wide area IP networks in Europe and elsewhere (http://www.ripe.net).
No comments:
Post a Comment