IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Pulling it all together - New Section 11 on Security Considerations
I like it. But I've one nit about the MITM section: it speaks of two
MITM possibilities, describes a "first" case and *two* "second" cases!
Cheers,
Nico
On Wed, May 21, 2003 at 12:36:49PM -0700, Chris Lonvick wrote:
> Hi Folks,
>
> Below is the latest version of the Security Considerations section. This
> reflects all of the discussions on the lists on the various parts of this
> over the past few weeks. I appreciate all of the feedback and help.
>
> I've also put together an html document of the changes from the previous
> version; red strike outs for deletions and green text for insertions.
> I'll put it on a web server and send around a pointer rsn. [The server
> isn't doing so well today but I think it will be fixed in the next day
> or so.] If you'd like to see that sooner rather than later, please email
> me directly and I'll send it to you.
>
> If you would like to suggest any changes, please call out the relevent
> section in the Subject line of your email. Also, please remove the
> non-related sections from your reply as this thing is getting a bit long.
>
> Thanks,
> Chris
>
> ==========================================================================
>
>
> 11. Security Considerations
>
> In order to make the entire body of Security Considerations more
> accessible, Security Considerations for the transport, authentication,
> and connection documents have been gathered here.
>
> The transport protocol [SSH-TRANS] provides a confidential channel
> over an insecure network. It performs server host authentication, key
> exchange, encryption, and integrity protection. It also derives a
> unique session id that may be used by higher-level protocols.
>
> The authentication protocol [SSH-USERAUTH] provides a suite of
> mechanisms which can be used to authenticatethe client user to the
> server. Individual mechanisms specified in the in authentication
> protocol use the session id provided by the transport protocol and/or
> depend on the security and integrity guarantees of the transport
> protocol.
>
> The connection protocol [SSH-CONNECT] specifies a mechanism to
> multiplex multiple streams (channels) of data over the confidential
> and authenticated transport. It also specifies channels for accessing
> an interactive shell, for 'proxy-forwarding' various external
> protocols over the secure transport (including arbitrary TCP/IP
> protocols), and for accessing secure 'subsystems' on the server host.
>
>
> 11.1 PRNG
>
> This protocol binds each session key to the session by including
> random, session specific data in the hash used to produce session
> keys. Special care should be taken to ensure that all of the random
> numbers are of good quality. If the random data here (e.g., DH
> parameters) are pseudo-random then the pseudo-random number generator
> should be cryptographically secure (i.e., its next output not easily
> guessed even when knowing all previous outputs) and, furthermore,
> proper entropy needs to be added to the pseudo-random number
> generator. RFC 1750 [RFC1750] offers suggestions for sources of
> random numbers and entropy. Implementors should note the importance
> of entropy and the well-meant, anecdotal warning about the difficulty
> in properly implementing pseudo-random number generating functions.
>
> The amount of entropy available to a given client or server may
> sometimes be less than what is required. In this case one must either
> resort to pseudo-random number generation regardless of insufficient
> entropy or refuse to run the protocol. The latter is preferable.
>
>
> 11.2 Transport
>
>
> 11.2.1 Confidentiality
>
> It is beyond the scope of this document and the Secure Shell Working
> Group to analyze or recommend specific ciphers other than the ones
> which have been established and accepted within the industry. At the
> time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
> twofish, serpent and blowfish. AES has been accepted by The US Federal
> Information Processing Standards [FIPS-197] and the cryptographic
> community as being acceptable for this purpose as well. As always,
> implementors and users should check current literature to ensure that
> no recent vulnerabilities have been found in ciphers used within
> products. Implementors should also check to see which ciphers are
> considered to be relatively stronger than others and should recommend
> their use to users over relatively weaker ciphers. It would be
> considered good form for an implementation to politely and
> unobtrusively notify a user that a stronger cipher is available and
> should be used when a weaker one is actively chosen.
>
> The "none" cipher is provided for debugging and SHOULD NOT be used
> except for that purpose. It's cryptographic properties are
> sufficiently described in RFC 2410 [RFC2410], which will show that its
> use does not meet the intent of this protocol.
>
> The relative merits of these and other ciphers may also be found in
> current literature. Two references that may provide information on the
> subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these
> describe the CBC mode of operation of certain ciphers and the weakness
> of this scheme. Essentially, this mode is theoretically vulnerable to
> chosen cipher-text attacks because of the high predictability of the
> start of packet sequence. However, this attack is still deemed
> difficult and not considered fully practicable especially if relatively
> longer block sizes are used.
>
> Additionally, another CBC mode attack may be mitigated through the
> insertion of packets containing SSH_MSG_IGNORE. Without this
> technique, a specific attack may be successful. For this attack
> (commonly known as the Rogaway attack) to work, the attacker would
> need to know the IV of the next block that is going to be encrypted.
> In CBC mode that is the output of the encryption of the previous
> block. If the attacker does not have any way to see the packet yet
> (i.e it is in the internal buffers of the ssh implementation or even
> in the kernel) then this attack will not work. If the last packet has
> been sent out to the network (i.e the attacker has access to it) then
> he can use the attack.
>
> In the optimal case an implementor would need to add an extra packet
> only if the packet has been sent out onto the network and there are no
> other packets waiting for transmission. Implementors may wish to check
> to see if there are any unsent packets awaiting transmission, but
> unfortunately it is not normally easy to obtain this information from
> the kernel or buffers. If there are not, then a packet containing
> SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream
> every time the attacker knows the IV that is supposed to be used for
> the next packet, then the attacker will not be able to guess the
> correct IV, thus the attack will never be successfull.
>
> As an example, consider the following case:
>
> Client Server
> ------ ------
> TCP(seq=x, len=500) ->
> contains Record 1
>
> [500 ms passes, no ACK]
>
> TCP(seq=x, len=1000) ->
> contains Records 1,2
>
> <- ACK
>
>
> (1) The Nagle algorithm + TCP retransmits mean that the two
> records get coalesced into a single TCP segment
> (2) Record 2 is *not* at the beginning of the TCP segment
> and never will be, since it gets ACKed.
> (3) Yet, the attack is possible because Record 1 has already
> been seen.
>
> As this example indicates, it's totally unsafe to use the existence
> of unflushed data in the TCP buffers proper as a guide to whether
> you need an empty packet, since when you do the second write(),
> the buffers will contain the un-ACKed Record 1.
>
> On the other hand, it's perfectly safe to have the following
> situation:
>
> Client Server
> ------ ------
> TCP(seq=x, len=500) ->
> contains SSH_MSG_IGNORE
>
> TCP(seq=y, len=500) ->
> contains Data
>
> Provided that the IV for second SSH Record is fixed after the data for
> the Data packet is determined -i.e. you do:
> read from user
> encrypt null packet
> encrypt data packet
>
>
> 11.2.2 Data Integrity
>
> This protocol does allow the Data Integrity mechanism to be disabled.
> Implementors SHOULD be wary of exposing this feature for any purpose
> other than debugging. Users and administrators SHOULD be explicitly
> warned anytime the "none" MAC is enabled.
>
> So long as the "none" MAC is not used, this protocol
> provides data integrity.
>
> Because MACs use a 32 bit sequence number, they might start to leak
> information after 2**32 packets have been sent. However, following
> the rekeying recommendations should prevent this attack. The
> transport protocol [1] recommends rekeying after one gigabyte of data,
> and the smallest possible packet is 16 bytes. Therefore, rekeying
> SHOULD happen after 2**28 packets at the very most.
>
>
> 11.2.3 Replay
>
> The use of a MAC other than 'none' provides integrity and
> authentication. In addition, the transport protocol provides a unique
> session identifier (bound in part to pseudo-random data that is part
> of the algorithm and key exchange process) that can be used by higher
> level protocols to bind data to a given session and prevent replay of
> data from prior sessions. For example, the authentication protocol uses
> this to prevent replay of signatures from previous sessions. Because
> public key authentication exchanges are cryptographically bound to the
> session (i.e., to the initial key exchange) they cannot be successfully
> replayed in other sessions. Note that the session ID can be made
> public without harming the security of the protocol.
>
> If two session happen to have the same session ID [hash of key
> exchanges] then packets from one can be replayed against the other.
> It must be stressed that the chances of such an occurrence are,
> needless to say, minimal when using modern cryptographic methods.
> This is all the more so true when specifying larger hash function
> outputs and DH parameters.
>
> Replay detection using monotonically increasing sequence numbers as
> input to the MAC, or HMAC in some cases, is described in RFC 2085
> [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964],
> RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct
> is discussed in RFC 2104 [RFC2104]. Essentially a different sequence
> number in each packet ensures that at least this one input to the MAC
> function will be unique and will provide a nonrecurring MAC output
> that is not predictable to an attacker. If the session stays active
> long enough, however, this sequence number will wrap. This event may
> provide an attacker an opportunity to replay a previously recorded
> packet with an identical sequence number but only if the peers have
> not rekeyed since the transmission of the first packet with that
> sequence number. If the peers have rekeyed, then the replay will be
> detected as the MAC check will fail. For this reason, it must be
> emphasized that peers MUST rekey before a wrap of the sequence
> numbers. Naturally, if an attacker does attempt to replay a captured
> packet before the peers have rekeyed, then the receiver of the
> duplicate packet will not be able to validate the MAC and it will be
> discarded. The reason that the MAC will fail is because the receiver
> will formulate a MAC based upon the packet contents, the shared
> secret, and the expected sequence number. Since the replayed packet
> will not be using that expected sequence number (the sequence number
> of the replayed packet will have already been passed by the receiver)
> then the calculated MAC will not match the MAC received with the
> packet.
>
>
> 11.2.4 Man-in-the-middle
>
> This protocol makes no assumptions nor provisions for an
> infrastructure or means for distributing the public keys of hosts. It
> is expected that this protocol will sometimes be used without first
> verifying the association between the server host key and the server
> host name. Such usage is vulnerable to man-in-the-middle attacks.
> This section describes this and encourages administrators and users to
> understand the importance of verifying this association before any
> session is initiated.
>
> There are two cases of man-in-the-middle attacks to consider. The
> first is where an attacker places a device between the client and the
> server before the session is initiated. In this case, the attack
> device is trying to mimic the legitimate server and will offer its
> public key to the client when the client initiates a session. If it
> were to offer the public key of the server, then it would not be able
> to decrypt or sign the transmissions between the legitimate server and
> the client unless it also had access to the private-key of the host.
> The attack device will also, simultaneously to this, initiate a
> session to the legitimate server masquerading itself as the client.
> If the public key of the server had been securely distributed to the
> client prior to that session initiation, the key offered to the client
> by the attack device will not match the key stored on the client. In
> that case, the user SHOULD be given a warning that the offered host
> key does not match the host key cached on the client. As described in
> Section 3.1 of [SSH-ARCH], the user may be free to accept the new key
> and continue the session. It is RECOMMENDED that the warning provide
> sufficient information to the user of the client device so they may
> make an informed decision. If the user chooses to continue the
> session with the stored public-key of the server (not the public-key
> offered at the start of the session), then the session specific data
> between the attacker and server will be different between the
> client-to-attacker session and the attacker-to-server sessions due to
> the randomness discussed above. From this, the attacker will not be
> able to make this attack work since the attacker will not be able to
> correctly sign packets containing this session specific data from the
> server since he does not have the private key of that server.
>
> Insecure distribution of server public keys allows a second type of
> man-in-the-middle attack that should also be considered in this case;
> one with suitable but incorrect host keys. If the server public keys
> are not securely distributed then the client cannot know if it is
> talking to the intended server. An attacker may use social
> engineering techniques to pass off server keys to unsuspecting users
> and may then place a man-in-the-middle attack device between the
> legitimate server and the clients. If this is allowed to happen then
> the clients will form client-to-attacker sessions and the attacker
> will form attacker-to-server sessions and will be able to monitor and
> manipulate all of the traffic between the clients and the legitimate
> servers. Server administrators are encouraged to make host key
> fingerprints available for checking by some means whose security does
> not rely on the integrity of the actual host keys. Possible
> mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also
> include secured Web pages, physical pieces of paper, etc.
> Implementors SHOULD provide recommendations on how best to do this
> with their implementation. Because the protocol is extensible, future
> extensions to the protocol may provide better mechanisms for dealing
> with the need to know the server's host key before connecting. For
> example, making the host key fingerprint available through a secure
> DNS lookup, or using kerberos over gssapi during key exchange to
> authenticate the server are possibilities.
>
> As a second man-in-the-middle case, attackers may attempt to
> manipulate packets in transit between peers after the session has been
> established. As described in the Replay part of this section, a
> successful attack of this nature is very improbable. As in the Replay
> section, this reasoning does assume that the MAC is secure and that it
> is infeasible to construct inputs to a MAC algorithm to give a known
> output. This is discussed in much greater detail in Section 6 of RFC
> 2104. If the MAC algorithm has a vulnerability or is weak enough,
> then the attacker may be able to specify certain inputs to yield a
> known MAC. With that they may be able to alter the contents of a
> packet in transit. Alternatively the attacker may be able to exploit
> the algorithm vulnerability or weakness to find the shared secret by
> reviewing the MACs from captured packets. In either of those cases,
> an attacker could construct a packet or packets that could be inserted
> into an SSH stream. To prevent that, implementors are encouraged to
> utilize commonly accepted MAC algorithms and administrators are
> encouraged to watch current literature and discussions of cryptography
> to ensure that they are not using a MAC algorithm that has a recently
> found vulnerability or weakness.
>
> In summary, the use of this protocol without a reliable association of
> the binding between a host and its host keys is inherently insecure
> and is NOT RECOMMENDED. It may however be necessary in non-security
> critical environments, and will still provide protection against
> passive attacks. Implementors of protocols and applications running
> on top of this protocol should keep this possibility in mind.
>
>
> 11.2.5 Denial-of-service
>
> This protocol is designed to be used over a reliable transport. If
> transmission errors or message manipulation occur, the connection is
> closed. The connection SHOULD be re-established if this occurs.
> Denial of service attacks of this type ("wire cutter") are almost
> impossible to avoid.
>
> In addition, this protocol is vulnerable to Denial of Service
> attacks because an attacker can force the server to go through
> the CPU and memory intensive tasks of connection setup and
> key exchange without authenticating. Implementors SHOULD provide
> features that make this more difficult. For example, only allowing
> connections from a subset of IPs known to have valid users.
>
>
> 11.2.6 Covert Channels
>
> The protocol was not designed to eliminate covert channels. For
> example, the padding, SSH_MSG_IGNORE messages, and several other
> places in the protocol can be used to pass covert information, and
> the recipient has no reliable way to verify whether such information
> is being sent.
>
>
> 11.2.7 Forward Secrecy
>
> It should be noted that the Diffie-Hellman key exchanges may provide
> perfect forward secrecy (PFS). PFS is essentially defined as the
> cryptographic property of a key-establishment protocol in which the
> compromise of a session key or long-term private key after a given
> session does not cause the compromise of any earlier session.
> [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using
> diffie-hellman-group1-sha1 are secure even if private
> keying/authentication material is later revealed, but not if the
> session keys are revealed. So, given this definition of PFS, SSHv2
> does have PFS. It is hoped that all other key exchange mechanisms
> proposed and used in the future will also provide PFS. This property
> is not commuted to any of the applications or protocols using SSH as a
> transport however. The transport layer of SSH provides
> confidentiality for password authentication and other methods that
> rely on secret data.
>
> Of course, if the DH private parameters for the client and server are
> revealed then the session key is revealed, but these items can be
> thrown away after the key exchange completes. It's worth pointing out
> that these items should not be allowed to end up on swap space and
> that they should be erased from memory as soon as the key exchange
> completes.
>
>
> 11.3 Authentication Protocol
>
> The purpose of this protocol is to perform client user authentication.
> It assumes that this run over a secure transport layer protocol, which
> has already authenticated the server machine, established an encrypted
> communications channel, and computed a unique session identifier for
> this session.
>
> Several authentication methods with different security characteristics
> are allowed. It is up to the server's local policy to decide which
> methods (or combinations of methods) it is willing to accept for each
> user. Authentication is no stronger than the weakest combination
> allowed.
>
> The server may go into a "sleep" period after repeated unsuccessful
> authentication attempts to make key search more difficult for
> attackers. Care should be taken so that this doesn't become a
> self-denial of service vector.
>
>
> 11.3.1 Weak Transport
>
> If the transport layer does not provide confidentiality,
> authentication methods that rely on secret data SHOULD be disabled.
> If it does not provide strong integrity protection, requests to change
> authentication data (e.g. a password change) SHOULD be disabled to
> prevent an attacker from modifying the ciphertext without being
> noticed, or rendering the new authentication data unusable (denial
> of service).
>
> The assumption as stated above that the Authentication Protocol only
> run over a secure transport that has previously authenticated the
> server is very important to note. People deploying SSH are reminded
> of the consequences of man-in-the-middle attacks if the client does
> not have a very strong a priori association of the server with the
> host key of that server. Specifically for the case of the
> Authentication Protocol the client may form a session to a
> man-in-the-middle attack device and divulge user credentials such as
> their username and password. Even in the cases of authentication
> where no user credentials are divulged, an attacker may still gain
> information they shouldn't have by capturing key-strokes in much the
> same way that a honeypot works.
>
>
> 11.3.2 Debug messages
>
> Special care should be taken when designing debug messages. These
> messages may reveal surprising amounts of information about the host
> if not properly designed. Debug messages can be disabled (during
> user authentication phase) if high security is required.
>
>
> 11.3.3 Local security policy
>
> Implementer MUST ensure that the credentials provided validate the
> professed user and also MUST ensure that the local policy of the
> server permits the user the access requested. In particular,
> because of the flexible nature of the SSH connection protocol, it may
> not be possible to determine the local security policy, if any, that
> should apply at the time of authentication because the kind of service
> being requested is not clear at that instant. For example, local
> policy might allow a user to access files on the server, but not start
> an interactive shell. However, during the authentication protocol, it
> is not known whether the user will be accessing files or attempting to
> use an interactive shell, or even both. In any event, where local
> security policy for the server host exists, it MUST be applied and
> enforced correctly.
>
> Implementors are encouraged to provide a default local policy and
> make its parameters known to administrators and users. At the
> discretion of the implementors, this default policy may be along the
> lines of 'anything goes' where there are no restrictions placed upon
> users, or it may be along the lines of 'excessively restrictive' in
> which case the administrators will have to actively make changes to
> this policy to meet their needs. Alternatively, it may be some
> attempt at providing something practical and immediately useful to the
> administrators of the system so they don't have to put in much effort
> to get SSH working. Whatever choice is made MUST be applied and
> enforced as required above.
>
>
> 11.3.4 Public key authentication
>
> The use of public-key authentication assumes that the client host has
> not been compromised.
>
> This risk can be mitigated by the use of passphrases on private keys;
> however, this is not an enforceable policy. The use of smartcards, or
> other technology to make passphrases an enforceable policy is
> suggested.
>
> The server could require both password and public-key authentication,
> however, this requires the client to expose its password to the server
> (see section on password authentication below.)
>
>
> 11.3.5 Password authentication
>
> The password mechanism as specified in the authentication protocol
> assumes that the server has not been compromised. If the server has
> been compromised, using password authentication will reveal a valid
> username / password combination to the attacker, which may lead to
> further compromises.
>
> This vulnerability can be mitigated by using an alternative form of
> authentication. For example, public-key authentication makes no
> assumptions about security on the server.
>
>
> 11.3.6 Host based authentication
>
> Host based authentication assumes that the client has not been
> compromised. There are no mitigating strategies, other than to use
> host based authentication in combination with another authentication
> method.
>
>
> 11.4 Connection protocol
>
>
> 11.4.1 End point security
>
> End point security is assumed by the connection protocol. If the
> server has been compromised, any terminal sessions, port forwarding,
> or systems accessed on the host are compromised. There are no
> mitigating factors for this.
>
> If the client end point has been compromised, and the server fails to
> stop the attacker at the authentication protocol, all services exposed
> (either as subsystems or through forwarding) will be vulnerable to
> attack. Implementors SHOULD provide mechanisms for administrators to
> control which services are exposed to limit the vulnerability of other
> services.
>
> These controls might include controlling which machines and ports can
> be target in 'port-forwarding' operations, which users are allowed to
> use interactive shell facilities, or which users are allowed to use
> exposed subsystems.
>
>
> 11.4.2 Proxy forwarding
>
> The SSH connection protocol allows for proxy forwarding of other
> protocols such as SNMP, POP3, and HTTP. This may be a concern for
> network administrators who wish to control the access of certain
> applications by users located outside of their physical location.
> Essentially, the forwarding of these protocols may violate site
> specific security policies as they may be undetectably tunneled
> through a firewall. Implementors SHOULD provide an administrative
> mechanism to control the proxy forwarding functionality so that
> site specific security policies may be upheld.
>
> In addition, a reverse proxy forwarding functionality
> is available, which again can be used to bypass firewall
> controls.
>
> As indicated above, end-point security is assumed during
> proxy forwarding operations. Failure of end-point security
> will compromise all data passed over proxy forwarding.
>
>
> 11.4.3 X11 forwarding
>
> Another form of proxy forwarding provided by the ssh connection
> protocol is the forwarding of the X11 protocol. If end-point security
> has been compromised, X11 forwarding may allow attacks against the X11
> server. Users and administrators should, as a matter of course, use
> appropriate X11 security mechanisms to prevent unauthorized use of the
> X11 server. Implementors, administrators and users who wish to
> further explore the security mechanisms of X11 are invited to read
> [SCHEIFLER] and analyze previously reported problems with the
> interactions between SSH forwarding and X11 in CERT vulnerabilities
> VU#363181 and VU#118892 [CERT].
>
> X11 display forwarding with SSH, by itself, is not sufficient to
> correct well known problems with X11 security [VENEMA]. However, X11
> display forwarding in SSHv2 (or other, secure protocols), combined
> with actual and pseudo-displays which accept connections only over
> local IPC mechanisms authorized by permissions or ACLs, does correct
> many X11 security problems as long as the "none" MAC is not used. It
> is RECOMMENDED that X11 display implementations default to allowing
> display opens only over local IPC. It is RECOMMENDED that SSHv2
> server implementations that support X11 forwarding default to allowing
> display opens only over local IPC. On single-user systems it might be
> reasonable to default to allowing local display opens over TCP/IP.
>
> Implementors of the X11 forwarding protocol SHOULD implement the magic
> cookie access checking spoofing mechanism as described in [ssh-connect]
> as an additional mechanism to prevent unauthorized use of the proxy.
>
>
> References from this section:
>
> [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
> Service (V5)", RFC 1510, September 1993.
>
> [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
> RFC 1964, June 1996.
>
> [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
> Recommendations for Security", RFC 1750, December 1994.
>
> [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
> (SPKM)", RFC 2025, October 1996.
>
> [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay
> Prevention", RFC 2085, February 1997.
>
> [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
> Keyed-Hashing for Message Authentication", RFC 2104,
> February 1997.
>
> [RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version
> 1.0", RFC 2246, January 1999.
>
> [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
> Use With IPsec", RFC 2410, November 1998
>
> [RFC2743] Linn, J., "Generic Security Service Application Program
> Interface Version 2, Update 1", RFC 2743, January 2000.
>
> [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
> and Sons Publisher, 1996
>
> [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
> a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner,
> Prentice Hall Publisher, 1995
>
> [FIPS-197] National Institute of Standards and Technology,
> "Specification for the Advanced Encryption Standard (AES)"
> FIPS 197. November 26, 2001.
>
> [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
> Glossary 2000", American National Standards Institute, Inc.,
> Approved February 28, 2001.
>
>
> [SCHEIFLER] Scheifler, R., "X Window System : The Complete
> Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
> edition.", Digital Press ISBN 1555580882, Feburary
> 1992.
>
> [CERT] The CERT Coordination Center
> Software Engineering Institute
> Carnegie Mellon University
> Pittsburgh, PA 15213-3890
> U.S.A.
> ( http://www.cert.org/nav/index_red.html )
>
> [VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings
> of 6th USENIX Security Symposium, San Jose, CA, July 1996.
> http://www.usenix.org/publications/library/proceedings/sec96/venema.html
>
>
>
>
>
Home |
Main Index |
Thread Index |
Old Index