diff options
| author | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2001-07-20 17:50:31 +0000 |
|---|---|---|
| committer | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2001-07-20 17:50:31 +0000 |
| commit | ac95734359f80e3c7771f9807e0d57b8e87093e3 (patch) | |
| tree | 1ff4f329c129b9c1c5c74ed293e82926f1e2a043 | |
| parent | b63487a0ae5c0d4cbeeaa6d38f24a6ce6619d7dc (diff) | |
| download | gnutls-ac95734359f80e3c7771f9807e0d57b8e87093e3.tar.gz | |
added some kind of certificate checking
| -rw-r--r-- | configure.in | 2 | ||||
| -rw-r--r-- | doc/protocol/draft-ietf-tls-srp-00.txt | 504 | ||||
| -rw-r--r-- | doc/protocol/draft-ietf-tls-srp-01.txt | 728 | ||||
| -rw-r--r-- | doc/protocol/rfc2313.txt | 1067 | ||||
| -rw-r--r-- | lib/Makefile.am | 6 | ||||
| -rw-r--r-- | lib/auth_rsa.c | 2 | ||||
| -rw-r--r-- | lib/cert_verify.c | 34 | ||||
| -rw-r--r-- | lib/gnutls_cert.c | 18 | ||||
| -rw-r--r-- | lib/gnutls_cert.h | 8 | ||||
| -rw-r--r-- | lib/gnutls_errors.c | 1 | ||||
| -rw-r--r-- | lib/gnutls_errors_int.h | 1 | ||||
| -rw-r--r-- | lib/gnutls_hash_int.h | 8 | ||||
| -rw-r--r-- | lib/gnutls_int.h | 4 | ||||
| -rw-r--r-- | lib/gnutls_pk.c | 6 | ||||
| -rw-r--r-- | lib/gnutls_pk.h | 11 | ||||
| -rw-r--r-- | lib/gnutls_sig.h | 3 | ||||
| -rw-r--r-- | lib/gnutls_sig_check.c | 209 | ||||
| -rw-r--r-- | src/ca.pem | 18 | ||||
| -rw-r--r-- | src/cert.pem | 77 | ||||
| -rw-r--r-- | src/key.pem | 26 | ||||
| -rw-r--r-- | src/pkcs1.asn | 18 |
21 files changed, 2168 insertions, 583 deletions
diff --git a/configure.in b/configure.in index ee447eb2b2..fbefe534df 100644 --- a/configure.in +++ b/configure.in @@ -11,7 +11,7 @@ AC_DEFINE_UNQUOTED(T_OS, "$target_os") GNUTLS_MAJOR_VERSION=0 GNUTLS_MINOR_VERSION=1 -GNUTLS_MICRO_VERSION=4 +GNUTLS_MICRO_VERSION=8 GNUTLS_VERSION=$GNUTLS_MAJOR_VERSION.$GNUTLS_MINOR_VERSION.$GNUTLS_MICRO_VERSION AC_DEFINE_UNQUOTED(GNUTLS_VERSION, "$GNUTLS_VERSION") diff --git a/doc/protocol/draft-ietf-tls-srp-00.txt b/doc/protocol/draft-ietf-tls-srp-00.txt deleted file mode 100644 index 814b9205e7..0000000000 --- a/doc/protocol/draft-ietf-tls-srp-00.txt +++ /dev/null @@ -1,504 +0,0 @@ - - -Network Working Group D. Taylor -Internet-Draft Forge Research Pty Ltd -Expires: August 6, 2001 February 5, 2001 - - - Using SRP for TLS Authentication - draft-ietf-tls-srp-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 6, 2001. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This memo presents a technique for using the SRP (Secure Remote - Password) protocol as an authentication method for the TLS - (Transport Layer Security) protocol. - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 1] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -1. Introduction - - At the time of writing, TLS[1] uses public key certificiates with - RSA/DSA digital signatures, or Kerberos, for authentication. - - These authentication methods do not seem well suited to the - applications now being adapted to use TLS (IMAP[3], FTP[4], or - TELNET[5], for example). Given these protocols (and others like - them) are designed to use the user name and password method of - authentication, being able to use user names and passwords to - authenticate the TLS connection seems to be a useful feature. - - SRP[2] is an authentication method that allows the use of user names - and passwords in a safe manner. - - This document describes the use of the SRP authentication method for - TLS. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 2] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -2. SRP Authentication in TLS - -2.1 Modifications to the TLS Handshake Sequence - - The SRP protocol can not be implemented using the sequence of - handshake messages defined in [1] due to the sequence in which the - SRP messages must be sent. - - This document proposes a new sequence of handshake messages for - handshakes using the SRP authentication method. - -2.1.1 Message Sequence - - Handshake Message Flow for SRP Authentication - - Client Server - | | - Client Hello (U) ------------------------> | - | <---------------------------- Server Hello - | <---------------------------- Server Key Exchange (g, N, s) - Client Key Exchange (A) -----------------> | - | <---------------------------- Server Key Exchange (B) - | <---------------------------- Server Hello Done - change cipher spec | - Finished --------------------------------> | - | change cipher spec - | <---------------------------- Finished - | | - - The identifiers given after each message name refer to variables - defined in [2] that are sent in that message. - - This new handshake sequence has a number of differences from the - standard TLS handshake sequence: - - o The client hello message has the user name appended to the - message. This is allowable as stated in section 7.4.1.2 of [1]. - - o The client cannot generate its its public key (A) until after it - has received the (g) and (N) paramters from the server, and the - client must send its public key before it receives the servers - public key (B) (as stated in section 3 of [2]). This means the - client must wait for a server key exchange message containing (g) - and (N), send a client key exchange message containing (A), and - then wait for another server key exchange message containing (B). - - o There is no server identification in this version of a TLS - handshake. If an attacker gets the SRP password file, they can - masquerade as the real system. - - -Taylor Expires August 6, 2001 [Page 3] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -2.2 Changes to the Handshake Message Contents - - This section describes the changes to the TLS handshake message - contents when SRP is being used for authentication. The details of - the on-the-wire changes are given in Section 2.5. - -2.2.1 The Client Hello Message - - The user name is appended to the standard client hello message. The - extra data is included in the handshake message hashes. - -2.2.2 The First Server Key Exchange Message - - The server key exchange message in the first round contains the - generator (g), the prime (N), and the salt value (s) read from the - SRP password file. - -2.2.3 The Client Key Exchange Message - - The client key exchange message carries the clients public key (A), - which is calculated using both information known locally, and - information received in the first server key exchange message. This - message MUST be sent between the first and second server key - exchange messages. - -2.2.4 The Second Server Key Exchange Message - - The server key exchange message in the second round contains the - servers public key (B). - -2.3 Calculating the Pre-master Secret - - The shared secret resulting from the SRP calculations (S) is used as - the pre-master secret. - - The finished messages perform the same function as the client and - server evidence messages specified in [2]. If either the client or - the server calculate an incorrect value, the finished messages will - not be understood, and the connection will be dropped as specified - in [1]. - -2.4 Cipher Suite Definitions - - The following cipher suites are added by this draft. The numbers - have been left blank until a suitable range has been selected. - - CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_SHA = { ?,? }; - - CipherSuite TLS_SRP_WITH_RC4_128_SHA = { ?,? }; - - -Taylor Expires August 6, 2001 [Page 4] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - - CipherSuite TLS_SRP_WITH_IDEA_CBC_SHA = { ?,? }; - - CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_MD5 = { ?,? }; - - CipherSuite TLS_SRP_WITH_RC4_128_MD5 = { ?,? }; - - CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { ?,? }; - -2.5 New Message Structures - - This section shows the structure of the messages passed during a - handshake that uses SRP for authentication. The representation - language used is that used in [1]. - - opaque Username<1..2^8-1>; - - enum { non_srp, srp } CipherSuiteType; - - struct { - ProtocolVersion client_version; - Random random; - SessionID session_id; - CipherSuite cipher_suites<2..2^16-1>; - - /* Need a better way to show the optional user_name field */ - select (CipherSuiteType) { - case non_srp: - CompressionMethod compression_methods<1..2^8-1>; - case srp: - CompressionMethod compression_methods<1..2^8-1>; - Username user_name; /* new entry */ - }; - } ClientHello; - - enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; - - enum { first, second } KeyExchangeRound; - - struct { - select (KeyExchangeRound) { - case first: - opaque srp_s<1..2^8-1> - opaque srp_N<1..2^16-1>; - opaque srp_g<1..2^16-1>; - case second: - opaque srp_B<1..2^16-1>; - }; - } ServerSRPParams; /* SRP parameters */ - - - -Taylor Expires August 6, 2001 [Page 5] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - - struct { - select (KeyExchangeAlgorithm) { - case diffie_hellman: - ServerDHParams params; - Signature signed_params; - case rsa: - ServerRSAParams params; - Signature signed_params; - case srp: - ServerSRPParams params; /* new entry */ - }; - } ServerKeyExchange; - - struct { - opaque srp_A<1..2^16-1>; - } SRPClientEphemeralPublic; - - struct { - select (KeyExchangeAlgorithm) { - case rsa: EncryptedPreMasterSecret; - case diffie_hellman: ClientDiffieHellmanPublic; - case srp: SRPClientEphemeralPublic; /* new entry */ - } exchange_keys; - } ClientKeyExchange; - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 6] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -3. Security Considerations - - There is no server identification in this version of a TLS - handshake. If an attacker gets the SRP password file, they can - masquerade as the real system. - - What are the security issues of this new handshake sequence? Are the - SRP parameters passed in a safe order? Is it a problem having the - username appended to the client hello message? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 7] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -References - - [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January - 1999. - - [2] Wu, T., "The SRP Authentication and Key Exchange System", RFC - 2945, September 2000. - - [3] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, - June 1999. - - [4] Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and - V. Wiegand, "Securing FTP with TLS", - draft-murray-auth-ftp-ssl-06 (work in progress), September 2000. - - [5] Boe, M. and J. Altman, "TLS-based Telnet Security", - draft-ietf-tn3270e-telnet-tls-05 (work in progress), October - 2000. - - -Author's Address - - David Taylor - Forge Research Pty Ltd - - EMail: DavidTaylor@forge.com.au - URI: http://www.protekt.com/ - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 8] - -Internet-Draft Using SRP for TLS Authentication February 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Taylor Expires August 6, 2001 [Page 9] - diff --git a/doc/protocol/draft-ietf-tls-srp-01.txt b/doc/protocol/draft-ietf-tls-srp-01.txt new file mode 100644 index 0000000000..f122ddd944 --- /dev/null +++ b/doc/protocol/draft-ietf-tls-srp-01.txt @@ -0,0 +1,728 @@ + + +Network Working Group D. Taylor +Internet-Draft Forge Research Pty Ltd +Expires: December 28, 2001 June 29, 2001 + + + Using SRP for TLS Authentication + draft-ietf-tls-srp-01 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 28, 2001. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This memo presents a technique for using the SRP (Secure Remote + Password) protocol as an authentication method for the TLS (Transport + Layer Security) protocol. + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 1] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . 4 + 2.1 Modifications to the TLS Handshake Sequence . . . . . . . . 4 + 2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.2 Session re-use . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 SRP Verifier Message Digest Selection . . . . . . . . . . . 5 + 2.3 Changes to the Handshake Message Contents . . . . . . . . . 5 + 2.3.1 The Client Hello Message . . . . . . . . . . . . . . . . . . 6 + 2.3.2 The Server Hello Message . . . . . . . . . . . . . . . . . . 6 + 2.3.3 The Client Key Exchange Message . . . . . . . . . . . . . . 6 + 2.3.4 The Server Key Exchange Message . . . . . . . . . . . . . . 6 + 2.4 Calculating the Pre-master Secret . . . . . . . . . . . . . 6 + 2.5 Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 6 + 2.6 New Message Structures . . . . . . . . . . . . . . . . . . . 7 + 2.6.1 ExtensionType . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.6.4 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 8 + 2.6.5 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 9 + 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 + References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 2] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +1. Introduction + + At the time of writing, TLS [1] uses public key certificiates with + RSA/DSA digital signatures, or Kerberos, for authentication. + + These authentication methods do not seem well suited to the + applications now being adapted to use TLS (IMAP [3], FTP [4], or + TELNET [5], for example). Given these protocols (and others like + them) are designed to use the user name and password method of + authentication, being able to use user names and passwords to + authenticate the TLS connection seems to be a useful feature. + + SRP [2] is an authentication method that allows the use of user names + and passwords over unencrypted channels without revealing the + password to an eavesdropper. SRP also supplies a shared secret at + the end of the authetication sequence that can be used to generate + encryption keys. + + This document describes the use of the SRP authentication method for + TLS. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 3] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +2. SRP Authentication in TLS + +2.1 Modifications to the TLS Handshake Sequence + + The SRP protocol can not be implemented using the sequence of + handshake messages defined in [1] due to the sequence in which the + SRP messages must be sent. + + This document proposes a new sequence of handshake messages for + handshakes using the SRP authentication method. + +2.1.1 Message Sequence + + Handshake Message Flow for SRP Authentication + + Client Server + | | + Client Hello (U, mds)--------------------> | + | <---------------------------- Server Hello (md, g, N, s) + Client Key Exchange (A) -----------------> | + | <---------------------------- Server Key Exchange (B) + | <---------------------------- Server Hello Done + change cipher spec | + Finished --------------------------------> | + | change cipher spec + | <---------------------------- Finished + | | + + The identifiers given after each message name refer to the SRP + variables included in that message. The variables are defined in + [2], except for (mds) and (md) which are defined in this document. + + Extended client and server hello messages, as defined in [6], are + used to to send the initial client and server values. + + The client key exchange message is sent during the sequence of server + messages. This modification is required because the client must send + its public key (A) before it receives the servers public key (B), as + stated in Section 3 of [2]. + +2.1.2 Session re-use + + The short handshake mechanism for re-using sessions for new + connections, and renegotiating keys for existing connections will + still work with the SRP authentication mechanism and handshake. + + When a client attemps to re-use a session that uses SRP + authentication, it MUST still include the SRP extension carrying the + + + +Taylor Expires December 28, 2001 [Page 4] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + + user name (U) in the client hello message, in case the server cannot + or will not allow re-use of the session, meaning a full handshake + sequence is required. + + If a client requests an existing session and the server agrees to use + it (meaning the short handshake will be used), the server MAY omit + the SRP extension from the server hello message, as the information + it contains is not used in the short handshake. + +2.2 SRP Verifier Message Digest Selection + + SRP uses a message digest algorithm when creating password verifiers, + and when performing calculations during authentication. At the time + of writing, SHA-1 is the only algorithm that has been defined for use + with SRP. However, there is no reason other message digest + algorithms cannot be used, and the handshake messages and extensions + defined by this draft include a message digest algorithm selection + mechanism. + + The passwordMessageDigest enumerated, the srp_mds vector, and srp_md + value are used to determine which message digest alorithm is to be + used by the client when it is performing the SRP calculation. The + server determines which message digest algorithm to use based on the + list of message digest algorithms requested by the client, and the + list of available SRP verifiers known by the server. + + The client sends a list of message digest algorithms it can use for + the SRP calculation using the srp_mds vector. The server MUST select + a message digest algorithm that is in the list supplied by the + client, and the server MUST have access to an SRP verifier calculated + with the selected message digest algorithm. + + If the server has access to multiple SRP verifiers for the given user + (each calculated using a different message disgest algorithm), the + server may select whichever matching message digest algorithm it + chooses, so long as the selected message digest algorithm appears in + the list sent by the client. + + If the server does not have an SRP verifier calculated with any of + the message digest algorithms suggested by the client, the server + must send a handshake failure alert. + +2.3 Changes to the Handshake Message Contents + + This section describes the changes to the TLS handshake message + contents when SRP is being used for authentication. The definitons + of the new message contents and the on-the-wire changes are given in + Section 2.6. + + + +Taylor Expires December 28, 2001 [Page 5] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +2.3.1 The Client Hello Message + + The user name is appended to the standard client hello message using + the client hello extension mechanism defined in [6]. + + The list of message digests the client can use is also included. + This list represents all the message digests the client can use for + the SRP calculations. + +2.3.2 The Server Hello Message + + The message digest selected by the server (md), the generator (g), + the prime (N), and the salt value (s) read from the SRP password file + are appended to the server hello message using the client hello + extension mechanism defined in [6]. + +2.3.3 The Client Key Exchange Message + + The client key exchange message carries the client's public key (A), + which is calculated using both information known locally, and + information received in the server hello message. This message MUST + be sent before the server key exchange message. + +2.3.4 The Server Key Exchange Message + + The server key exchange message contains the servers public key (B). + The server key exchange message MUST be sent after the client key + exchange message. + +2.4 Calculating the Pre-master Secret + + The shared secret resulting from the SRP calculations (S) (defined in + [2]) is used as the pre-master secret. + + The finished messages perform the same function as the client and + server evidence messages specified in [2]. If either the client or + the server calculate an incorrect value, the finished messages will + not be understood, and the connection will be dropped as specified in + [1]. + +2.5 Cipher Suite Definitions + + The following cipher suites are added by this draft. The numbers + have been selected based on other RFCs and Internet Drafts that were + current at the time of writing, so may need to be changed in future. + + CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_SHA = { 0x00,0x5B }; + + + + +Taylor Expires December 28, 2001 [Page 6] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + + CipherSuite TLS_SRP_WITH_RC4_128_SHA = { 0x00,0x5C }; + + CipherSuite TLS_SRP_WITH_IDEA_CBC_SHA = { 0x00,0x5D }; + + CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x5E }; + + CipherSuite TLS_SRP_WITH_RC4_128_MD5 = { 0x00,0x5F }; + + CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x60 }; + + +2.6 New Message Structures + + This section shows the structure of the messages passed during a + handshake that uses SRP for authentication. The representation + language used is the same as that used in [1]. + + When encoding the numbers g, N, A, and B as opaque types, if the most + significant bit is set, an extra byte of value 0x00 (all bits + cleared) MUST be added as the most significant byte. This is done as + a safeguard against implementations that do not assume these numbers + are positive. + +2.6.1 ExtensionType + + A new value, "srp(6)", has been added to the enumerated + ExtensionType, defined in [6]. This value is used as the extension + number for the extensions in both the client hello message and the + server hello message. This value was chosen based on the version of + defined in [6] that was current at the time of writing, so may be + changed in future. + +2.6.2 Client Hello + + The user name (U) and a list of message digests (srp_mds) are encoded + in an SRPExtension structure, and sent in an extended client hello + message, using an extension of type "srp". + + The list of message digests represents the list of message digests + the client can use for the SRP calculations. + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 7] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + + enum { client, server } ClientOrServerExtension; + + enum { sha-1(0), (255) } PasswordMessageDigest; + + struct { + select(ClientOrServerExtension) { + case client: + opaque srp_U<1..2^8-1>; + PasswordMessageDigest srp_mds<1..2^8-1>; + case server: + PasswordMessageDigest srp_md; + opaque srp_s<1..2^8-1> + opaque srp_N<1..2^16-1>; + opaque srp_g<1..2^16-1>; + } + } SRPExtension; + + +2.6.3 Server Hello + + The message digest selected by the server (md), the generator (g), + the prime (N), and the salt value (s) are encoded in an SRPExtension + structure, which is sent in an extended server hello message, using + an extension of type "srp". + + The SRPParams structure is defined above. + +2.6.4 Client Key Exchange + + When the value of KeyExchangeAlgorithm is set to "srp", the client's + ephemeral public key (A) is sent in the client key exchange message, + encoded in an ClientSRPPublic structure. + + An extra value, srp, has been added to the enumerated + KeyExchangeAlgorithm, originally defined in TLS [1]. + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 8] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: ClientDiffieHellmanPublic; + case srp: ClientSRPPublic; /* new entry */ + } exchange_keys; + } ClientKeyExchange; + + enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; + + struct { + opaque srp_A<1..2^16-1>; + } ClientSRPPublic; + + +2.6.5 Server Key Exchange + + When the value of KeyExchangeAlgorithm is set to "srp", the server's + ephemeral public key (B) is sent in the server key exchange message, + encoded in an ServerSRPPublic structure. + + struct { + select (KeyExchangeAlgorithm) { + case diffie_hellman: + ServerDHParams params; + Signature signed_params; + case rsa: + ServerRSAParams params; + Signature signed_params; + case srp: + ServerSRPPublic; /* new entry */ + }; + } ServerKeyExchange; + + struct { + opaque srp_B<1..2^16-1>; + } ServerSRPPublic; /* SRP parameters */ + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 9] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +3. Security Considerations + + If an attacker is able to steal the SRP verifier file, the attacker + can masquerade as the real host. Filesystem based X.509 certificate + installations are vulnerable to a similar attack unless the servers + certificate is issued from a PKI that maintains revocation lists, and + the client TLS code can both contact the PKI and make use of the + revocation list. + + Not all clients and servers will be able to interoperate once the + number of message digest algorithms used for creating password + verifiers is increased. For example, a client may only support SHA- + 1, whereas the verifiers on the server were created with a different + message digest algoritm. + + Because the initial handshake messages are unprotected, an attacker + can modify the list of message digests in the client hello message. + For example, an attacker could rewrite the message to remove all but + the weakest message digest. There is no way to know this has + happened until the finished messages are compared. + + An attacker can also modify the server hello message to use a + different message digest than that selected by the server. If this + happens, the handshake will fail after the change cipher spec + messages are sent, as the client and server will have calculated + different pre-master secret vales. + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 10] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +References + + [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January + 1999. + + [2] Wu, T., "The SRP Authentication and Key Exchange System", RFC + 2945, September 2000. + + [3] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June + 1999. + + [4] Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and + V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl- + 06 (work in progress), September 2000. + + [5] Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf- + tn3270e-telnet-tls-05 (work in progress), October 2000. + + [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. + Wright, "TLS Extensions", draft-ietf-tls-extensions-00 (work in + progress), June 2001. + + +Author's Address + + David Taylor + Forge Research Pty Ltd + + EMail: DavidTaylor@forge.com.au + URI: http://www.forge.com.au/ + + + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 11] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +Appendix A. Acknowledgements + + The following people have contributed ideas and time to this draft: + Raif Naffah, Tom Wu, Nikos Mavroyanopoulos + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 12] + +Internet-Draft Using SRP for TLS Authentication June 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Taylor Expires December 28, 2001 [Page 13] + diff --git a/doc/protocol/rfc2313.txt b/doc/protocol/rfc2313.txt new file mode 100644 index 0000000000..f9471eba6b --- /dev/null +++ b/doc/protocol/rfc2313.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group B. Kaliski +Request for Comments: 2313 RSA Laboratories East +Category: Informational March 1998 + + + PKCS #1: RSA Encryption + Version 1.5 + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Overview + + This document describes a method for encrypting data using the RSA + public-key cryptosystem. + +1. Scope + + This document describes a method for encrypting data using the RSA + public-key cryptosystem. Its intended use is in the construction of + digital signatures and digital envelopes, as described in PKCS #7: + + o For digital signatures, the content to be signed + is first reduced to a message digest with a + message-digest algorithm (such as MD5), and then + an octet string containing the message digest is + encrypted with the RSA private key of the signer + of the content. The content and the encrypted + message digest are represented together according + to the syntax in PKCS #7 to yield a digital + signature. This application is compatible with + Privacy-Enhanced Mail (PEM) methods. + + o For digital envelopes, the content to be enveloped + is first encrypted under a content-encryption key + with a content-encryption algorithm (such as DES), + and then the content-encryption key is encrypted + with the RSA public keys of the recipients of the + content. The encrypted content and the encrypted + + + + + +Kaliski Informational [Page 1] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + content-encryption key are represented together + according to the syntax in PKCS #7 to yield a + digital envelope. This application is also + compatible with PEM methods. + + The document also describes a syntax for RSA public keys and private + keys. The public-key syntax would be used in certificates; the + private-key syntax would be used typically in PKCS #8 private-key + information. The public-key syntax is identical to that in both X.509 + and Privacy-Enhanced Mail. Thus X.509/PEM RSA keys can be used in + this document. + + The document also defines three signature algorithms for use in + signing X.509/PEM certificates and certificate-revocation lists, PKCS + #6 extended certificates, and other objects employing digital + signatures such as X.401 message tokens. + + Details on message-digest and content-encryption algorithms are + outside the scope of this document, as are details on sources of the + pseudorandom bits required by certain methods in this document. + +2. References + + FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: + Data Encryption Standard. January 1988. + + PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate + Syntax. Version 1.5, November 1993. + + PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message + Syntax. Version 1.5, November 1993. + + PKCS #8 RSA Laboratories. PKCS #8: Private-Key Information + Syntax. Version 1.2, November 1993. + + RFC 1319 Kaliski, B., "The MD2 Message-Digest + Algorithm," RFC 1319, April 1992. + + RFC 1320 Rivest, R., "The MD4 Message-Digest + Algorithm," RFC 1320, April 1992. + + RFC 1321 Rivest, R., "The MD5 Message-Digest + Algorithm," RFC 1321, April 1992. + + RFC 1423 Balenson, D., "Privacy Enhancement for + Internet Electronic Mail: Part III: Algorithms, + Modes, and Identifiers," RFC 1423, February 1993. + + + + +Kaliski Informational [Page 2] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + X.208 CCITT. Recommendation X.208: Specification of + Abstract Syntax Notation One (ASN.1). 1988. + + X.209 CCITT. Recommendation X.209: Specification of + Basic Encoding Rules for Abstract Syntax Notation + One (ASN.1). 1988. + + X.411 CCITT. Recommendation X.411: Message Handling + Systems: Message Transfer System: Abstract Service + Definition and Procedures.1988. + + X.509 CCITT. Recommendation X.509: The Directory-- + Authentication Framework. 1988. + + [dBB92] B. den Boer and A. Bosselaers. An attack on the + last two rounds of MD4. In J. Feigenbaum, editor, + Advances in Cryptology---CRYPTO '91 Proceedings, + volume 576 of Lecture Notes in Computer Science, + pages 194-203. Springer-Verlag, New York, 1992. + + [dBB93] B. den Boer and A. Bosselaers. Collisions for the + compression function of MD5. Presented at + EUROCRYPT '93 (Lofthus, Norway, May 24-27, 1993). + + [DO86] Y. Desmedt and A.M. Odlyzko. A chosen text attack + on the RSA cryptosystem and some discrete + logarithm schemes. In H.C. Williams, editor, + Advances in Cryptology---CRYPTO '85 Proceedings, + volume 218 of Lecture Notes in Computer Science, + pages 516-521. Springer-Verlag, New York, 1986. + + [Has88] Johan Hastad. Solving simultaneous modular + equations. SIAM Journal on Computing, + 17(2):336-341, April 1988. + + [IM90] Colin I'Anson and Chris Mitchell. Security defects + in CCITT Recommendation X.509--The directory + authentication framework. Computer Communications + Review, :30-34, April 1990. + + [Mer90] R.C. Merkle. Note on MD4. Unpublished manuscript, + 1990. + + [Mil76] G.L. Miller. Riemann's hypothesis and tests for + primality. Journal of Computer and Systems + Sciences, 13(3):300-307, 1976. + + + + + +Kaliski Informational [Page 3] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + [QC82] J.-J. Quisquater and C. Couvreur. Fast + decipherment algorithm for RSA public-key + cryptosystem. Electronics Letters, 18(21):905-907, + October 1982. + + [RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method + for obtaining digital signatures and public-key + cryptosystems. Communications of the ACM, + 21(2):120-126, February 1978. + +3. Definitions + + For the purposes of this document, the following definitions apply. + + AlgorithmIdentifier: A type that identifies an algorithm (by object + identifier) and associated parameters. This type is defined in X.509. + + ASN.1: Abstract Syntax Notation One, as defined in X.208. + + BER: Basic Encoding Rules, as defined in X.209. + + DES: Data Encryption Standard, as defined in FIPS PUB 46-1. + + MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as + defined in RFC 1319. + + MD4: RSA Data Security, Inc.'s MD4 message-digest algorithm, as + defined in RFC 1320. + + MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as + defined in RFC 1321. + + modulus: Integer constructed as the product of two primes. + + PEM: Internet Privacy-Enhanced Mail, as defined in RFC 1423 and + related documents. + + RSA: The RSA public-key cryptosystem, as defined in [RSA78]. + + private key: Modulus and private exponent. + + public key: Modulus and public exponent. + +4. Symbols and abbreviations + + Upper-case symbols (e.g., BT) denote octet strings and bit strings + (in the case of the signature S); lower-case symbols (e.g., c) denote + integers. + + + +Kaliski Informational [Page 4] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + ab hexadecimal octet value c exponent + BT block type d private exponent + D data e public exponent + EB encryption block k length of modulus in + octets + ED encrypted data n modulus + M message p, q prime factors of modulus + MD message digest x integer encryption block + MD' comparative message y integer encrypted data + digest + PS padding string mod n modulo n + S signature X || Y concatenation of X, Y + ||X|| length in octets of X +5. General overview + + The next six sections specify key generation, key syntax, the + encryption process, the decryption process, signature algorithms, and + object identifiers. + + Each entity shall generate a pair of keys: a public key and a private + key. The encryption process shall be performed with one of the keys + and the decryption process shall be performed with the other key. + Thus the encryption process can be either a public-key operation or a + private-key operation, and so can the decryption process. Both + processes transform an octet string to another octet string. The + processes are inverses of each other if one process uses an entity's + public key and the other process uses the same entity's private key. + + The encryption and decryption processes can implement either the + classic RSA transformations, or variations with padding. + +6. Key generation + + This section describes RSA key generation. + + Each entity shall select a positive integer e as its public exponent. + + Each entity shall privately and randomly select two distinct odd + primes p and q such that (p-1) and e have no common divisors, and + (q-1) and e have no common divisors. + + The public modulus n shall be the product of the private prime + factors p and q: + + n = pq . + + The private exponent shall be a positive integer d such that de-1 is + divisible by both p-1 and q-1. + + + +Kaliski Informational [Page 5] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + The length of the modulus n in octets is the integer k satisfying + + 2^(8(k-1)) <= n < 2^(8k) . + + The length k of the modulus must be at least 12 octets to accommodate + the block formats in this document (see Section 8). + + Notes. + + 1. The public exponent may be standardized in + specific applications. The values 3 and F4 (65537) may have + some practical advantages, as noted in X.509 Annex C. + + 2. Some additional conditions on the choice of primes + may well be taken into account in order to deter + factorization of the modulus. These security conditions + fall outside the scope of this document. The lower bound on + the length k is to accommodate the block formats, not for + security. + +7. Key syntax + + This section gives the syntax for RSA public and private keys. + +7.1 Public-key syntax + + An RSA public key shall have ASN.1 type RSAPublicKey: + + RSAPublicKey ::= SEQUENCE { + modulus INTEGER, -- n + publicExponent INTEGER -- e } + + (This type is specified in X.509 and is retained here for + compatibility.) + + The fields of type RSAPublicKey have the following meanings: + + o modulus is the modulus n. + + o publicExponent is the public exponent e. + + + + + + + + + + + +Kaliski Informational [Page 6] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + +7.2 Private-key syntax + + An RSA private key shall have ASN.1 type RSAPrivateKey: + + RSAPrivateKey ::= SEQUENCE { + version Version, + modulus INTEGER, -- n + publicExponent INTEGER, -- e + privateExponent INTEGER, -- d + prime1 INTEGER, -- p + prime2 INTEGER, -- q + exponent1 INTEGER, -- d mod (p-1) + exponent2 INTEGER, -- d mod (q-1) + coefficient INTEGER -- (inverse of q) mod p } + + Version ::= INTEGER + + The fields of type RSAPrivateKey have the following meanings: + + o version is the version number, for compatibility + with future revisions of this document. It shall + be 0 for this version of the document. + + o modulus is the modulus n. + + o publicExponent is the public exponent e. + + o privateExponent is the private exponent d. + + o prime1 is the prime factor p of n. + + o prime2 is the prime factor q of n. + + o exponent1 is d mod (p-1). + + o exponent2 is d mod (q-1). + + o coefficient is the Chinese Remainder Theorem + coefficient q-1 mod p. + + Notes. + + 1. An RSA private key logically consists of only the + modulus n and the private exponent d. The presence of the + values p, q, d mod (p-1), d mod (p-1), and q-1 mod p is + intended for efficiency, as Quisquater and Couvreur have + shown [QC82]. A private-key syntax that does not include + + + + +Kaliski Informational [Page 7] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + all the extra values can be converted readily to the syntax + defined here, provided the public key is known, according + to a result by Miller [Mil76]. + + 2. The presence of the public exponent e is intended + to make it straightforward to derive a public key from the + private key. + +8. Encryption process + + This section describes the RSA encryption process. + + The encryption process consists of four steps: encryption- block + formatting, octet-string-to-integer conversion, RSA computation, and + integer-to-octet-string conversion. The input to the encryption + process shall be an octet string D, the data; an integer n, the + modulus; and an integer c, the exponent. For a public-key operation, + the integer c shall be an entity's public exponent e; for a private- + key operation, it shall be an entity's private exponent d. The output + from the encryption process shall be an octet string ED, the + encrypted data. + + The length of the data D shall not be more than k-11 octets, which is + positive since the length k of the modulus is at least 12 octets. + This limitation guarantees that the length of the padding string PS + is at least eight octets, which is a security condition. + + Notes. + + 1. In typical applications of this document to + encrypt content-encryption keys and message digests, one + would have ||D|| <= 30. Thus the length of the RSA modulus + will need to be at least 328 bits (41 octets), which is + reasonable and consistent with security recommendations. + + 2. The encryption process does not provide an + explicit integrity check to facilitate error detection + should the encrypted data be corrupted in transmission. + However, the structure of the encryption block guarantees + that the probability that corruption is undetected is less + than 2-16, which is an upper bound on the probability that + a random encryption block looks like block type 02. + + 3. Application of private-key operations as defined + here to data other than an octet string containing a + message digest is not recommended and is subject to further + study. + + + + +Kaliski Informational [Page 8] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + 4. This document may be extended to handle data of + length more than k-11 octets. + +8.1 Encryption-block formatting + + A block type BT, a padding string PS, and the data D shall be + formatted into an octet string EB, the encryption block. + + EB = 00 || BT || PS || 00 || D . (1) + + The block type BT shall be a single octet indicating the structure of + the encryption block. For this version of the document it shall have + value 00, 01, or 02. For a private- key operation, the block type + shall be 00 or 01. For a public-key operation, it shall be 02. + + The padding string PS shall consist of k-3-||D|| octets. For block + type 00, the octets shall have value 00; for block type 01, they + shall have value FF; and for block type 02, they shall be + pseudorandomly generated and nonzero. This makes the length of the + encryption block EB equal to k. + + Notes. + + 1. The leading 00 octet ensures that the encryption + block, converted to an integer, is less than the modulus. + + 2. For block type 00, the data D must begin with a + nonzero octet or have known length so that the encryption + block can be parsed unambiguously. For block types 01 and + 02, the encryption block can be parsed unambiguously since + the padding string PS contains no octets with value 00 and + the padding string is separated from the data D by an octet + with value 00. + + 3. Block type 01 is recommended for private-key + operations. Block type 01 has the property that the + encryption block, converted to an integer, is guaranteed to + be large, which prevents certain attacks of the kind + proposed by Desmedt and Odlyzko [DO86]. + + 4. Block types 01 and 02 are compatible with PEM RSA + encryption of content-encryption keys and message digests + as described in RFC 1423. + + + + + + + + +Kaliski Informational [Page 9] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + 5. For block type 02, it is recommended that the + pseudorandom octets be generated independently for each + encryption process, especially if the same data is input to + more than one encryption process. Hastad's results [Has88] + motivate this recommendation. + + 6. For block type 02, the padding string is at least + eight octets long, which is a security condition for + public-key operations that prevents an attacker from + recoving data by trying all possible encryption blocks. For + simplicity, the minimum length is the same for block type + 01. + + 7. This document may be extended in the future to + include other block types. + +8.2 Octet-string-to-integer conversion + + The encryption block EB shall be converted to an integer x, the + integer encryption block. Let EB1, ..., EBk be the octets of EB from + first to last. Then the integer x shall satisfy + + k + x = SUM 2^(8(k-i)) EBi . (2) + i = 1 + + In other words, the first octet of EB has the most significance in + the integer and the last octet of EB has the least significance. + + Note. The integer encryption block x satisfies 0 <= x < n since EB1 + = 00 and 2^(8(k-1)) <= n. + +8.3 RSA computation + + The integer encryption block x shall be raised to the power c modulo + n to give an integer y, the integer encrypted data. + + y = x^c mod n, 0 <= y < n . + + This is the classic RSA computation. + +8.4 Integer-to-octet-string conversion + + The integer encrypted data y shall be converted to an octet string ED + of length k, the encrypted data. The encrypted data ED shall satisfy + + + + + + +Kaliski Informational [Page 10] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + k + y = SUM 2^(8(k-i)) EDi . (3) + i = 1 + + where ED1, ..., EDk are the octets of ED from first to last. + + In other words, the first octet of ED has the most significance in + the integer and the last octet of ED has the least significance. + +9. Decryption process + + This section describes the RSA decryption process. + + The decryption process consists of four steps: octet-string-to- + integer conversion, RSA computation, integer-to-octet-string + conversion, and encryption-block parsing. The input to the decryption + process shall be an octet string ED, the encrypted data; an integer + n, the modulus; and an integer c, the exponent. For a public-key + operation, the integer c shall be an entity's public exponent e; for + a private-key operation, it shall be an entity's private exponent d. + The output from the decryption process shall be an octet string D, + the data. + + It is an error if the length of the encrypted data ED is not k. + + For brevity, the decryption process is described in terms of the + encryption process. + +9.1 Octet-string-to-integer conversion + + The encrypted data ED shall be converted to an integer y, the integer + encrypted data, according to Equation (3). + + It is an error if the integer encrypted data y does not satisfy 0 <= + y < n. + +9.2 RSA computation + + The integer encrypted data y shall be raised to the power c modulo n + to give an integer x, the integer encryption block. + + x = y^c mod n, 0 <= x < n . + + This is the classic RSA computation. + + + + + + + +Kaliski Informational [Page 11] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + +9.3 Integer-to-octet-string conversion + + The integer encryption block x shall be converted to an octet string + EB of length k, the encryption block, according to Equation (2). + +9.4 Encryption-block parsing + + The encryption block EB shall be parsed into a block type BT, a + padding string PS, and the data D according to Equation (1). + + It is an error if any of the following conditions occurs: + + o The encryption block EB cannot be parsed + unambiguously (see notes to Section 8.1). + + o The padding string PS consists of fewer than eight + octets, or is inconsistent with the block type BT. + + o The decryption process is a public-key operation + and the block type BT is not 00 or 01, or the decryption + process is a private-key operation and the block type is + not 02. + +10. Signature algorithms + + This section defines three signature algorithms based on the RSA + encryption process described in Sections 8 and 9. The intended use of + the signature algorithms is in signing X.509/PEM certificates and + certificate-revocation lists, PKCS #6 extended certificates, and + other objects employing digital signatures such as X.401 message + tokens. The algorithms are not intended for use in constructing + digital signatures in PKCS #7. The first signature algorithm + (informally, "MD2 with RSA") combines the MD2 message-digest + algorithm with RSA, the second (informally, "MD4 with RSA") combines + the MD4 message-digest algorithm with RSA, and the third (informally, + "MD5 with RSA") combines the MD5 message-digest algorithm with RSA. + + This section describes the signature process and the verification + process for the two algorithms. The "selected" message-digest + algorithm shall be either MD2 or MD5, depending on the signature + algorithm. The signature process shall be performed with an entity's + private key and the verification process shall be performed with an + entity's public key. The signature process transforms an octet string + (the message) to a bit string (the signature); the verification + process determines whether a bit string (the signature) is the + signature of an octet string (the message). + + + + + +Kaliski Informational [Page 12] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + Note. The only difference between the signature algorithms defined + here and one of the the methods by which signatures (encrypted + message digests) are constructed in PKCS #7 is that signatures here + are represented here as bit strings, for consistency with the X.509 + SIGNED macro. In PKCS #7 encrypted message digests are octet strings. + +10.1 Signature process + + The signature process consists of four steps: message digesting, data + encoding, RSA encryption, and octet-string-to-bit-string conversion. + The input to the signature process shall be an octet string M, the + message; and a signer's private key. The output from the signature + process shall be a bit string S, the signature. + +10.1.1 Message digesting + + The message M shall be digested with the selected message- digest + algorithm to give an octet string MD, the message digest. + +10.1.2 Data encoding + + The message digest MD and a message-digest algorithm identifier shall + be combined into an ASN.1 value of type DigestInfo, described below, + which shall be BER-encoded to give an octet string D, the data. + + DigestInfo ::= SEQUENCE { + digestAlgorithm DigestAlgorithmIdentifier, + digest Digest } + + DigestAlgorithmIdentifier ::= AlgorithmIdentifier + + Digest ::= OCTET STRING + + The fields of type DigestInfo have the following meanings: + + o digestAlgorithm identifies the message-digest + algorithm (and any associated parameters). For + this application, it should identify the selected + message-digest algorithm, MD2, MD4 or MD5. For + reference, the relevant object identifiers are the + following: + + + + + + + + + + +Kaliski Informational [Page 13] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + md2 OBJECT IDENTIFIER ::= + + { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 2 } md4 OBJECT IDENTIFIER ::= + { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 4 } md5 OBJECT IDENTIFIER ::= + { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5 } + + For these object identifiers, the parameters field of the + digestAlgorithm value should be NULL. + + o digest is the result of the message-digesting + process, i.e., the message digest MD. + + Notes. + + 1. A message-digest algorithm identifier is included + in the DigestInfo value to limit the damage resulting from + the compromise of one message-digest algorithm. For + instance, suppose an adversary were able to find messages + with a given MD2 message digest. That adversary might try + to forge a signature on a message by finding an innocuous- + looking message with the same MD2 message digest, and + coercing a signer to sign the innocuous-looking message. + This attack would succeed only if the signer used MD2. If + the DigestInfo value contained only the message digest, + however, an adversary could attack signers that use any + message digest. + + 2. Although it may be claimed that the use of a + SEQUENCE type violates the literal statement in the X.509 + SIGNED and SIGNATURE macros that a signature is an + ENCRYPTED OCTET STRING (as opposed to ENCRYPTED SEQUENCE), + such a literal interpretation need not be required, as + I'Anson and Mitchell point out [IM90]. + + 3. No reason is known that MD4 would not be + for very high security digital signature schemes, but + because MD4 was designed to be exceptionally fast, it is + "at the edge" in terms of risking successful cryptanalytic + attack. A message-digest algorithm can be considered + "broken" if someone can find a collision: two messages with + the same digest. While collisions have been found in + variants of MD4 with only two digesting "rounds" + + + + + + +Kaliski Informational [Page 14] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + [Mer90][dBB92], none have been found in MD4 itself, which + has three rounds. After further critical review, it may be + appropriate to consider MD4 for very high security + applications. + + MD5, which has four rounds and is proportionally slower + than MD4, is recommended until the completion of MD4's + review. The reported "pseudocollisions" in MD5's internal + compression function [dBB93] do not appear to have any + practical impact on MD5's security. + + MD2, the slowest of the three, has the most conservative + design. No attacks on MD2 have been published. + +10.1.3 RSA encryption + + The data D shall be encrypted with the signer's RSA private key as + described in Section 7 to give an octet string ED, the encrypted + data. The block type shall be 01. (See Section 8.1.) + +10.1.4 Octet-string-to-bit-string conversion + + The encrypted data ED shall be converted into a bit string S, the + signature. Specifically, the most significant bit of the first octet + of the encrypted data shall become the first bit of the signature, + and so on through the least significant bit of the last octet of the + encrypted data, which shall become the last bit of the signature. + + Note. The length in bits of the signature S is a multiple of eight. + +10.2 Verification process + + The verification process for both signature algorithms consists of + four steps: bit-string-to-octet-string conversion, RSA decryption, + data decoding, and message digesting and comparison. The input to the + verification process shall be an octet string M, the message; a + signer's public key; and a bit string S, the signature. The output + from the verification process shall be an indication of success or + failure. + +10.2.1 Bit-string-to-octet-string conversion + + The signature S shall be converted into an octet string ED, the + encrypted data. Specifically, assuming that the length in bits of the + signature S is a multiple of eight, the first bit of the signature + shall become the most significant bit of the first octet of the + + + + + +Kaliski Informational [Page 15] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + encrypted data, and so on through the last bit of the signature, + which shall become the least significant bit of the last octet of the + encrypted data. + + It is an error if the length in bits of the signature S is not a + multiple of eight. + +10.2.2 RSA decryption + + The encrypted data ED shall be decrypted with the signer's RSA public + key as described in Section 8 to give an octet string D, the data. + + It is an error if the block type recovered in the decryption process + is not 01. (See Section 9.4.) + +10.2.3 Data decoding + + The data D shall be BER-decoded to give an ASN.1 value of type + DigestInfo, which shall be separated into a message digest MD and a + message-digest algorithm identifier. The message-digest algorithm + identifier shall determine the "selected" message-digest algorithm + for the next step. + + It is an error if the message-digest algorithm identifier does not + identify the MD2, MD4 or MD5 message-digest algorithm. + +10.2.4 Message digesting and comparison + + The message M shall be digested with the selected message-digest + algorithm to give an octet string MD', the comparative message + digest. The verification process shall succeed if the comparative + message digest MD' is the same as the message digest MD, and the + verification process shall fail otherwise. + +11. Object identifiers + + This document defines five object identifiers: pkcs-1, rsaEncryption, + md2WithRSAEncryption, md4WithRSAEncryption, and md5WithRSAEncryption. + + The object identifier pkcs-1 identifies this document. + + pkcs-1 OBJECT IDENTIFIER ::= + + { iso(1) member-body(2) US(840) rsadsi(113549) + pkcs(1) 1 } + + + + + + +Kaliski Informational [Page 16] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + The object identifier rsaEncryption identifies RSA public and private + keys as defined in Section 7 and the RSA encryption and decryption + processes defined in Sections 8 and 9. + + rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } + + The rsaEncryption object identifier is intended to be used in the + algorithm field of a value of type AlgorithmIdentifier. The + parameters field of that type, which has the algorithm-specific + syntax ANY DEFINED BY algorithm, would have ASN.1 type NULL for this + algorithm. + + The object identifiers md2WithRSAEncryption, md4WithRSAEncryption, + md5WithRSAEncryption, identify, respectively, the "MD2 with RSA," + "MD4 with RSA," and "MD5 with RSA" signature and verification + processes defined in Section 10. + + md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } + md4WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 3 } + md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } + + These object identifiers are intended to be used in the algorithm + field of a value of type AlgorithmIdentifier. The parameters field of + that type, which has the algorithm-specific syntax ANY DEFINED BY + algorithm, would have ASN.1 type NULL for these algorithms. + + Note. X.509's object identifier rsa also identifies RSA public keys + as defined in Section 7, but does not identify private keys, and + identifies different encryption and decryption processes. It is + expected that some applications will identify public keys by rsa. + Such public keys are compatible with this document; an rsaEncryption + process under an rsa public key is the same as the rsaEncryption + process under an rsaEncryption public key. + +Security Considerations + + Security issues are discussed throughout this memo. + +Revision history + + Versions 1.0-1.3 + + Versions 1.0-1.3 were distributed to participants in RSA Data + Security, Inc.'s Public-Key Cryptography Standards meetings in + February and March 1991. + + + + + + +Kaliski Informational [Page 17] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + + Version 1.4 + + Version 1.4 is part of the June 3, 1991 initial public release of + PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop + document SEC-SIG-91-18. + + Version 1.5 + + Version 1.5 incorporates several editorial changes, including updates + to the references and the addition of a revision history. The + following substantive changes were made: + + o Section 10: "MD4 with RSA" signature and + verification processes are added. + + o Section 11: md4WithRSAEncryption object identifier + is added. + + Supersedes June 3, 1991 version, which was also published as NIST/OSI + Implementors' Workshop document SEC-SIG-91-18. + +Acknowledgements + + This document is based on a contribution of RSA Laboratories, a + division of RSA Data Security, Inc. Any substantial use of the text + from this document must acknowledge RSA Data Security, Inc. RSA Data + Security, Inc. requests that all material mentioning or referencing + this document identify this as "RSA Data Security, Inc. PKCS #1". + +Author's Address + + Burt Kaliski + RSA Laboratories East + 20 Crosby Drive + Bedford, MA 01730 + + Phone: (617) 687-7000 + EMail: burt@rsa.com + + + + + + + + + + + + + +Kaliski Informational [Page 18] + +RFC 2313 PKCS #1: RSA Encryption March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Kaliski Informational [Page 19] + diff --git a/lib/Makefile.am b/lib/Makefile.am index 1849a52e82..bea7d8fee2 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -15,7 +15,8 @@ EXTRA_DIST = debug.h gnutls_compress.h defines.h \ crypt.h libgnutls-config.in libgnutls.m4 gnutls.h.in gnutls_errors_int.h \ cert_asn1.h cert_der.h gnutls_datum.h auth_x509.h gnutls_gcry.h \ ext_dnsname.h gnutls_pk.h gnutls_record.h gnutls_cert.h \ - gnutls_privkey.h gnutls_constate.h gnutls_global.h cert_verify.h + gnutls_privkey.h gnutls_constate.h gnutls_global.h cert_verify.h \ + gnutls_sig.h lib_LTLIBRARIES = libgnutls.la libgnutls_la_SOURCES = gnutls_record.c gnutls_compress.c debug.c \ gnutls_cipher.c gnutls_buffers.c gnutls_handshake.c gnutls_num.c \ @@ -27,6 +28,7 @@ libgnutls_la_SOURCES = gnutls_record.c gnutls_compress.c debug.c \ auth_srp.c auth_srp_passwd.c gnutls_v2_compat.c auth_srp_sb64.c \ cert_ASN.y cert_asn1.c cert_der.c gnutls_datum.c auth_rsa.c \ gnutls_gcry.c ext_dnsname.c gnutls_pk.c gnutls_cert.c cert_verify.c\ - gnutls_global.c gnutls_privkey.c gnutls_constate.c gnutls_anon_cred.c + gnutls_global.c gnutls_privkey.c gnutls_constate.c gnutls_anon_cred.c \ + gnutls_sig_check.c libgnutls_la_LDFLAGS = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) diff --git a/lib/auth_rsa.c b/lib/auth_rsa.c index e06467dc23..a05d87cf8e 100644 --- a/lib/auth_rsa.c +++ b/lib/auth_rsa.c @@ -311,7 +311,7 @@ int proc_rsa_client_kx(GNUTLS_KEY key, opaque * data, int data_size) } ret = _gnutls_pkcs1_rsa_decrypt(&plaintext, ciphertext, key->u, - key->A); + key->A, 2); /* btype==2 */ if (ret < 0) { /* in case decryption fails then don't inform diff --git a/lib/cert_verify.c b/lib/cert_verify.c index 14d65fd3c4..4f78e502bd 100644 --- a/lib/cert_verify.c +++ b/lib/cert_verify.c @@ -25,6 +25,7 @@ #include "cert_der.h" #include "gnutls_global.h" #include "gnutls_num.h" /* GMAX */ +#include <gnutls_sig.h> /* TIME functions */ @@ -169,12 +170,14 @@ int compare_dn(gnutls_cert * cert, gnutls_cert * issuer_cert) opaque issuer_dn[MAX_DN]; opaque dn[MAX_DN]; +fprintf(stderr, "XXX: %s\nIII: %s\n", cert->issuer_info.common_name, issuer_cert->cert_info.common_name); /* get the issuer of 'cert' */ if (asn1_create_structure(_gnutls_get_pkix(), "PKIX1Implicit88.Certificate", &c2, "certificate2") != ASN_OK) { gnutls_assert(); return GNUTLS_E_ASN1_ERROR; } + result = asn1_get_der(c2, cert->raw.data, cert->raw.size); if (result != ASN_OK) { /* couldn't decode DER */ @@ -182,9 +185,10 @@ int compare_dn(gnutls_cert * cert, gnutls_cert * issuer_cert) asn1_delete_structure(c2); return GNUTLS_E_ASN1_PARSING_ERROR; } + issuer_len = sizeof(issuer_dn) - 1; if ((result = - asn1_read_value(c2, "certificate2.tbsCertificate.subject.rdnSequence", issuer_dn, &issuer_len)) < 0) { + asn1_read_value(c2, "certificate2.tbsCertificate.issuer.rdnSequence", issuer_dn, &issuer_len)) < 0) { gnutls_assert(); asn1_delete_structure(c2); return GNUTLS_E_ASN1_PARSING_ERROR; @@ -198,6 +202,7 @@ int compare_dn(gnutls_cert * cert, gnutls_cert * issuer_cert) gnutls_assert(); return GNUTLS_E_ASN1_ERROR; } + result = asn1_get_der(c2, issuer_cert->raw.data, issuer_cert->raw.size); if (result != ASN_OK) { /* couldn't decode DER */ @@ -205,6 +210,7 @@ int compare_dn(gnutls_cert * cert, gnutls_cert * issuer_cert) asn1_delete_structure(c2); return GNUTLS_E_ASN1_PARSING_ERROR; } + len = sizeof(dn) - 1; if ((result = asn1_read_value(c2, "certificate2.tbsCertificate.subject.rdnSequence", dn, &len)) < 0) { @@ -214,10 +220,13 @@ int compare_dn(gnutls_cert * cert, gnutls_cert * issuer_cert) } asn1_delete_structure(c2); +fprintf(stderr, "len: %d\nisslen: %d\n", len,issuer_len); + if (memcmp(dn, issuer_dn, GMAX(len, issuer_len)) == 0) return 0; - return -1; /* do not match */ + gnutls_assert(); + return GNUTLS_E_UNKNOWN_ERROR; /* do not match */ } @@ -233,6 +242,7 @@ static gnutls_cert *find_issuer(gnutls_cert * cert, gnutls_cert * trusted_cas, i return &trusted_cas[i]; } + gnutls_assert(); return NULL; } @@ -245,15 +255,23 @@ int gnutls_verify_certificate2(gnutls_cert * cert, gnutls_cert * trusted_cas, in gnutls_cert *issuer; CertificateStatus ret = GNUTLS_CERT_NOT_TRUSTED; - if (tcas_size > 1) + if (tcas_size >= 1) issuer = find_issuer(cert, trusted_cas, tcas_size); + else { + gnutls_assert(); + return ret; + } + /* issuer is not in trusted certificate * authorities. */ - if (issuer == NULL) + if (issuer == NULL) { + gnutls_assert(); return GNUTLS_CERT_NOT_TRUSTED; - -// ret = verify_signature(cert, issuer); + } +fprintf(stderr, "XXXissuer: %d\n", issuer->subject_pk_algorithm); + + ret = gnutls_verify_signature(cert, issuer); if (ret != GNUTLS_CERT_TRUSTED) return ret; @@ -279,9 +297,9 @@ int gnutls_verify_certificate(gnutls_cert * certificate_list, if (tcas_size == 0) { return ret; } - + for (i = 0; i < clist_size; i++) { - if (i + 1 > clist_size) + if (i + 1 >= clist_size) break; if ((ret = gnutls_verify_certificate2(&certificate_list[i], &certificate_list[i + 1], 1, NULL, 0)) != GNUTLS_CERT_TRUSTED) { diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c index 003e657215..b670332c10 100644 --- a/lib/gnutls_cert.c +++ b/lib/gnutls_cert.c @@ -82,7 +82,7 @@ int n,i; for (i=0;i<n;i++) { _gnutls_mpi_release( &cert.params[i]); } - gnutls_free( cert.params); + if (cert.params!=NULL) gnutls_free( cert.params); gnutls_free_datum( &cert.raw); @@ -691,10 +691,22 @@ int _gnutls_cert2gnutlsCert(gnutls_cert * gCert, gnutls_datum derCert) * currently not supported */ gnutls_assert(); - asn1_delete_structure(c2); + gCert->subject_pk_algorithm = GNUTLS_PK_UNKNOWN; + gCert->params = NULL; + + } - return GNUTLS_E_UNIMPLEMENTED_FEATURE; + len = sizeof( gCert->signature); + result = + asn1_read_value + (c2, "certificate2.signature", + gCert->signature, &len); + if ((len % 8) !=0) { + gnutls_assert(); + asn1_delete_structure(c2); + return GNUTLS_E_UNIMPLEMENTED_FEATURE; } + gCert->signature_size = len; memset( &gCert->cert_info, 0, sizeof(gCert->cert_info)); diff --git a/lib/gnutls_cert.h b/lib/gnutls_cert.h index 89777e23c9..b76ff71fb2 100644 --- a/lib/gnutls_cert.h +++ b/lib/gnutls_cert.h @@ -1,6 +1,8 @@ #ifndef GNUTLS_CERT_H # define GNUTLS_CERT_H +#include <gnutls_pk.h> + typedef struct { char common_name[256]; char country[3]; @@ -10,9 +12,6 @@ typedef struct { char state_or_province_name[256]; } gnutls_DN; -typedef enum PKAlgorithm { GNUTLS_PK_RSA = 1, GNUTLS_PK_DSA, /* sign only */ - GNUTLS_PK_DH -} PKAlgorithm; typedef struct { MPI *params; /* the size of params depends on the public @@ -23,6 +22,9 @@ typedef struct { gnutls_DN cert_info; gnutls_DN issuer_info; + opaque signature[MAX_HASH_SIZE]; + int signature_size; + time_t expiration_time; time_t activation_time; diff --git a/lib/gnutls_errors.c b/lib/gnutls_errors.c index e804936b8e..5a147fe759 100644 --- a/lib/gnutls_errors.c +++ b/lib/gnutls_errors.c @@ -60,6 +60,7 @@ static gnutls_error_entry error_algorithms[] = { GNUTLS_ERROR_ENTRY( GNUTLS_E_ENCRYPTION_FAILED, 1), GNUTLS_ERROR_ENTRY( GNUTLS_E_PK_DECRYPTION_FAILED, 1), GNUTLS_ERROR_ENTRY( GNUTLS_E_PK_ENCRYPTION_FAILED, 1), + GNUTLS_ERROR_ENTRY( GNUTLS_E_PK_SIGNATURE_FAILED, 1), GNUTLS_ERROR_ENTRY( GNUTLS_E_DECOMPRESSION_FAILED, 1), GNUTLS_ERROR_ENTRY( GNUTLS_E_COMPRESSION_FAILED, 1), GNUTLS_ERROR_ENTRY( GNUTLS_E_MEMORY_ERROR, 1), diff --git a/lib/gnutls_errors_int.h b/lib/gnutls_errors_int.h index 3b04dea8fc..e89a2c7194 100644 --- a/lib/gnutls_errors_int.h +++ b/lib/gnutls_errors_int.h @@ -43,5 +43,6 @@ #define GNUTLS_E_X509_CERTIFICATE_ERROR -43 #define GNUTLS_E_PK_ENCRYPTION_FAILED -44 #define GNUTLS_E_PK_DECRYPTION_FAILED -45 +#define GNUTLS_E_PK_SIGNATURE_FAILED -46 #define GNUTLS_E_UNIMPLEMENTED_FEATURE -250 diff --git a/lib/gnutls_hash_int.h b/lib/gnutls_hash_int.h index 3b0dbfa23c..be368331db 100644 --- a/lib/gnutls_hash_int.h +++ b/lib/gnutls_hash_int.h @@ -40,7 +40,7 @@ typedef struct { int keysize; } GNUTLS_MAC_HANDLE_INT; typedef GNUTLS_MAC_HANDLE_INT* GNUTLS_MAC_HANDLE; - +typedef GNUTLS_MAC_HANDLE GNUTLS_HASH_HANDLE; #define GNUTLS_HASH_FAILED NULL #define GNUTLS_MAC_FAILED NULL @@ -55,10 +55,10 @@ void gnutls_hmac_deinit( GNUTLS_MAC_HANDLE handle, void* digest); GNUTLS_MAC_HANDLE gnutls_mac_init_ssl3( MACAlgorithm algorithm, void* key, int keylen); void gnutls_mac_deinit_ssl3( GNUTLS_MAC_HANDLE handle, void* digest); -GNUTLS_MAC_HANDLE gnutls_hash_init(MACAlgorithm algorithm); +GNUTLS_HASH_HANDLE gnutls_hash_init(MACAlgorithm algorithm); int gnutls_hash_get_algo_len(MACAlgorithm algorithm); -int gnutls_hash(GNUTLS_MAC_HANDLE handle, const void* text, int textlen); -void gnutls_hash_deinit(GNUTLS_MAC_HANDLE handle, void* digest); +int gnutls_hash(GNUTLS_HASH_HANDLE handle, const void* text, int textlen); +void gnutls_hash_deinit(GNUTLS_HASH_HANDLE handle, void* digest); void *gnutls_ssl3_generate_random(void *secret, int secret_len, void *random, int random_len, int bytes); diff --git a/lib/gnutls_int.h b/lib/gnutls_int.h index 3481a29d24..663e3689cd 100644 --- a/lib/gnutls_int.h +++ b/lib/gnutls_int.h @@ -30,9 +30,9 @@ #define HARD_DEBUG #define BUFFERS_DEBUG #define RECORD_DEBUG -#define HANDSHAKE_DEBUG +#define HANDSHAKE_DEBUG*/ #define DEBUG -*/ + #define SOCKET int #define LIST ... diff --git a/lib/gnutls_pk.c b/lib/gnutls_pk.c index b7bbfc58a4..76b06ce6a0 100644 --- a/lib/gnutls_pk.c +++ b/lib/gnutls_pk.c @@ -110,7 +110,7 @@ int _gnutls_pkcs1_rsa_encrypt(gnutls_datum * ciphertext, gnutls_datum plaintext, */ int _gnutls_pkcs1_rsa_decrypt(gnutls_datum * plaintext, gnutls_datum ciphertext, - MPI pkey, MPI n) + MPI pkey, MPI n, int btype) { int k, esize, i, ret; MPI c, res; @@ -153,13 +153,13 @@ int _gnutls_pkcs1_rsa_decrypt(gnutls_datum * plaintext, gnutls_datum ciphertext, gcry_mpi_release(res); /* EB = 00||BT||PS||00||D - * (use block type 2) + * (use block type 'btype') */ edata[0] = 0; esize++; - if (edata[0] != 0 || edata[1] != 2) { + if (edata[0] != 0 || edata[1] != btype) { gnutls_assert(); gnutls_free(edata); return GNUTLS_E_DECRYPTION_FAILED; diff --git a/lib/gnutls_pk.h b/lib/gnutls_pk.h index f6eb0328c7..d6e2d5d673 100644 --- a/lib/gnutls_pk.h +++ b/lib/gnutls_pk.h @@ -1,5 +1,14 @@ +#ifndef GNUTLS_PK_H +# define GNUTLS_PK_H + +typedef enum PKAlgorithm { GNUTLS_PK_RSA = 1, GNUTLS_PK_DSA, /* sign only */ + GNUTLS_PK_DH, GNUTLS_PK_UNKNOWN +} PKAlgorithm; + int _gnutls_pk_encrypt(int algo, MPI * resarr, MPI data, MPI ** pkey); int _gnutls_pkcs1_rsa_encrypt(gnutls_datum * ciphertext, gnutls_datum plaintext, MPI pkey, MPI n); int _gnutls_pkcs1_rsa_decrypt(gnutls_datum * plaintext, gnutls_datum ciphertext, - MPI pkey, MPI n); + MPI pkey, MPI n, int btype); + +#endif /* GNUTLS_PK_H */ diff --git a/lib/gnutls_sig.h b/lib/gnutls_sig.h new file mode 100644 index 0000000000..c8a759884f --- /dev/null +++ b/lib/gnutls_sig.h @@ -0,0 +1,3 @@ +int _gnutls_pkcs1_rsa_verify_sig( gnutls_datum* signature, gnutls_datum *text, MPI m, MPI e); +CertificateStatus gnutls_verify_signature(gnutls_cert* cert, gnutls_cert* issuer); + diff --git a/lib/gnutls_sig_check.c b/lib/gnutls_sig_check.c new file mode 100644 index 0000000000..c96e17fa6a --- /dev/null +++ b/lib/gnutls_sig_check.c @@ -0,0 +1,209 @@ +/* + * Copyright (C) 2001 Nikos Mavroyanopoulos + * + * This file is part of GNUTLS. + * + * GNUTLS is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * GNUTLS is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + */ + +#include <gnutls_int.h> +#include <gnutls_errors.h> +#include <cert_b64.h> +#include <auth_x509.h> +#include <gnutls_cert.h> +#include <cert_asn1.h> +#include <cert_der.h> +#include <gnutls_datum.h> +#include <gnutls_gcry.h> +#include <gnutls_privkey.h> +#include <gnutls_global.h> +#include <gnutls_pk.h> + +static gnutls_datum* _gnutls_get_tbs( gnutls_cert* cert) { +node_asn *c2; +gnutls_datum * ret; +opaque str[10*1024]; +int result, len; + + if (asn1_create_structure( _gnutls_get_pkix(), "Certificate", &c2, "certificate")!=ASN_OK) { + gnutls_assert(); + return NULL; + } + + result = asn1_get_der( c2, cert->raw.data, cert->raw.size); + if (result != ASN_OK) { + gnutls_assert(); + asn1_delete_structure(c2); + return NULL; + } + + len = sizeof(str)-1; + result = + asn1_read_value( c2, "certificate.tbsCertificate", str, &len); + if (result != ASN_OK) { + gnutls_assert(); + asn1_delete_structure(c2); + return NULL; + } + + asn1_delete_structure(c2); + + ret = gnutls_malloc(sizeof(gnutls_cert)); + if (ret==NULL) { + gnutls_assert(); + return NULL; + } + + ret->data = gnutls_malloc( len); + if (ret->data==NULL) { + gnutls_assert(); + gnutls_free(ret); + return NULL; + } + + memcpy( ret->data, str, len); + ret->size = len; + + return ret; +} + + +/* we use DER here -- FIXME: use BER + */ +static int _gnutls_get_ber_digest_info( const gnutls_datum *info, MACAlgorithm *hash, opaque* digest, int digest_size) { +node_asn* dinfo; +int result; +opaque str[1024]; +int len; + + if (asn1_create_structure( _gnutls_get_pkcs(), "PKCS-1.DigestInfo", &dinfo, "digest_info")!=ASN_OK) { + gnutls_assert(); + return GNUTLS_E_ASN1_ERROR; + } + + result = asn1_get_der( dinfo, info->data, info->size); + if (result != ASN_OK) { + gnutls_assert(); + asn1_delete_structure(dinfo); + return GNUTLS_E_ASN1_PARSING_ERROR; + } + + len = sizeof(str)-1; + result = + asn1_read_value( dinfo, "digest_info.digestAlgorithm.algorithm", str, &len); + if (result != ASN_OK) { + gnutls_assert(); + asn1_delete_structure(dinfo); + return GNUTLS_E_ASN1_PARSING_ERROR; + } + + *hash = -1; + + if ( strcmp(str, "1 2 840 113549 2 5")==0) { /* MD5 */ + *hash = GNUTLS_MAC_MD5; + } else + if ( strcmp(str, "xxxxxx")==0) { /* SHA1 ID */ + *hash = GNUTLS_MAC_SHA; + } + + if (*hash==-1) { +fprintf(stderr, "OID: %s\n", str); + gnutls_assert(); + return GNUTLS_E_UNIMPLEMENTED_FEATURE; + } + + len = digest_size; + result = + asn1_read_value( dinfo, "digest_info.digest", digest, &len); + if (result != ASN_OK) { + gnutls_assert(); + asn1_delete_structure(dinfo); + return GNUTLS_E_ASN1_PARSING_ERROR; + } + + asn1_delete_structure(dinfo); + + return 0; +} + +/* if hash==MD5 then we do RSA-MD5 + * if hash==SHA then we do RSA-SHA + * m is modulus + * e is public key + */ +int +_gnutls_pkcs1_rsa_verify_sig( gnutls_datum* signature, gnutls_datum* text, MPI m, MPI e) +{ + MACAlgorithm hash; + int ret; + opaque digest[MAX_HASH_SIZE], md[MAX_HASH_SIZE]; + int digest_size; + GNUTLS_HASH_HANDLE hd; + gnutls_datum decrypted; + + + if ( (ret=_gnutls_pkcs1_rsa_decrypt( &decrypted, *signature, e, m, 1)) < 0) { + gnutls_assert(); + return ret; + } + + /* decrypted is a BER encoded data of type DigestInfo + */ + + if ( (ret = _gnutls_get_ber_digest_info( &decrypted, &hash, digest, sizeof(digest))) != 0) { + gnutls_assert(); + return ret; + } + + gnutls_free_datum( &decrypted); + + digest_size = gnutls_hash_get_algo_len(hash); + + hd = gnutls_hash_init(hash); + gnutls_hash(hd, text->data, text->size); + gnutls_hash_deinit(hd, md); + + if (memcmp( md, digest, digest_size)!=0) + return GNUTLS_E_PK_SIGNATURE_FAILED; + + return 0; +} + +CertificateStatus gnutls_verify_signature(gnutls_cert* cert, gnutls_cert* issuer) { +gnutls_datum signature; +gnutls_datum* tbs; + + if ( issuer->subject_pk_algorithm == GNUTLS_PK_RSA) { + signature.data = cert->signature; + signature.size = cert->signature_size; + + tbs = _gnutls_get_tbs( cert); + if (tbs==NULL) { + gnutls_assert(); + return GNUTLS_CERT_INVALID; + } + + if (_gnutls_pkcs1_rsa_verify_sig( &signature, tbs, issuer->params[1], issuer->params[0])!=0) { + gnutls_assert(); + gnutls_free_datum( tbs); + return GNUTLS_CERT_NOT_TRUSTED; + } + gnutls_free_datum(tbs); + return GNUTLS_CERT_TRUSTED; + } +fprintf(stderr, "PK: %d\n", issuer->subject_pk_algorithm); + gnutls_assert(); + return GNUTLS_CERT_INVALID; +} diff --git a/src/ca.pem b/src/ca.pem new file mode 100644 index 0000000000..8a77d91abb --- /dev/null +++ b/src/ca.pem @@ -0,0 +1,18 @@ +-----BEGIN CERTIFICATE----- +MIIC2jCCAkOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBmDELMAkGA1UEBhMCR1Ix +DzANBgNVBAgTBkF0dGlraTEPMA0GA1UEBxMGQXRoaW5hMRcwFQYDVQQKEw5HTlVU +TFMgVEVTVCBDQTEWMBQGA1UECxMNR05VVExTIERFVkVMLjEXMBUGA1UEAxMOR05V +VExTIFRFU1QgQ0ExHTAbBgkqhkiG9w0BCQEWDm5tYXZAaGVsbHVnLmdyMB4XDTAx +MDcyMDA3MTMyMFoXDTExMDcxODA3MTMyMFowgZgxCzAJBgNVBAYTAkdSMQ8wDQYD +VQQIEwZBdHRpa2kxDzANBgNVBAcTBkF0aGluYTEXMBUGA1UEChMOR05VVExTIFRF +U1QgQ0ExFjAUBgNVBAsTDUdOVVRMUyBERVZFTC4xFzAVBgNVBAMTDkdOVVRMUyBU +RVNUIENBMR0wGwYJKoZIhvcNAQkBFg5ubWF2QGhlbGx1Zy5ncjCBnzANBgkqhkiG +9w0BAQEFAAOBjQAwgYkCgYEAu3HbtQcFB+lQ/2OPEd14LKLRh3OzTNWZsem2rj6x +oHTuMaIWGuzgIrJAF92wfx5+qcNJ1ZttbfhHR84dbR8wISxeoTN8jA2vy6w6qsfk +/kuiZQb7NZML1l2tW+PzESnSxBuJSywoM6nu3Q17UeoZ4l2qgdY90iDI0lxh/0JK +Oi0CAwEAAaMyMDAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUhJDoDTbwcum9 +BaWIOdcRxlpWRbwwDQYJKoZIhvcNAQEEBQADgYEAcDd/j9F8F0AOPu1LnsS1DquV +7LNRApEj5OTw6tR7Xih9S8eDY2wzMi9szEykEIQ0qxOamA6V443xq4qDoturX1mg +E60rHVHNRmy9qcqvMKn7bt+11fgXE4Ya4do+hcBMwjuI4wmXDD160mFiiMHaVmUx +fy3Pa7F8RfUIMieurAU= +-----END CERTIFICATE----- diff --git a/src/cert.pem b/src/cert.pem index 9ee1ab08b8..274c0016e4 100644 --- a/src/cert.pem +++ b/src/cert.pem @@ -3,57 +3,58 @@ Certificate: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption - Issuer: C=GR, ST=Attiki, L=Athina, O=GNUTLS, OU=GNUTLS dev., CN=GNUTLS TEST CA/Email=gnutls-dev@gnupg.org + Issuer: C=GR, ST=Attiki, L=Athina, O=GNUTLS TEST CA, OU=GNUTLS DEVEL., CN=GNUTLS TEST CA/Email=nmav@hellug.gr Validity - Not Before: Jul 7 10:18:45 2001 GMT - Not After : Jul 7 10:18:45 2002 GMT - Subject: C=GR, ST=Attiki, L=Athina, O=GNUTLS, OU=GNUTLS dev., CN=localhost/Email=root@localhost + Not Before: Jul 20 07:16:46 2001 GMT + Not After : Jul 20 07:16:46 2002 GMT + Subject: C=GR, ST=Attiki, L=Athina, O=GNUTLS HTTP SERVER, OU=GNUTLS HTTP SERVER, CN=localhost/Email=nmav@hellug.gr Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): - 00:d0:0b:49:eb:b2:26:d9:51:f5:cc:57:07:21:99: - dd:f2:87:68:3d:2d:a1:a0:ef:cc:96:bf:f7:31:64: - 77:7c:78:c3:99:1e:92:ed:a6:65:84:e7:b9:7b:ab: - 4b:e6:8d:59:5d:22:55:57:e0:1e:7e:57:b5:c3:5c: - 04:b4:91:94:8c:5c:42:7a:d5:88:d8:c6:98:97:64: - 99:6d:6d:44:e1:7b:65:cc:fc:86:f3:b4:84:2d:e5: - 59:b7:30:c1:de:3a:ef:1c:e1:a3:28:af:f8:a3:57: - eb:a9:11:e1:f7:e8:fc:15:98:e2:1e:4b:f7:21:74: - 8c:58:7f:50:cf:46:15:7d:95 + 00:e0:c3:95:0b:66:ec:bf:a9:1f:9c:34:f6:e2:8f: + 5e:22:9a:d4:fe:1a:7b:54:13:cc:39:81:c0:b8:7e: + c1:43:1b:a4:fc:21:33:4d:ac:ac:14:69:d8:64:04: + 80:61:28:47:bd:cf:58:68:76:85:23:3c:4a:5a:c4: + 97:77:2a:9d:7b:93:45:5b:9b:03:d3:74:ae:db:f2: + 67:f5:24:0c:7f:36:82:a3:f0:85:de:b7:e0:ba:72: + 2f:39:ef:81:98:a3:12:32:a4:96:c7:36:c5:5b:27: + 0e:ff:7e:be:71:4a:23:5e:bf:e0:ef:8d:13:4b:67: + 68:d3:b6:88:df:a5:21:73:c1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: - keyid:EF:EE:94:AB:C8:CA:57:7F:53:13:DB:76:DC:1A:95:00:93:BA:F3:C9 + keyid:84:90:E8:0D:36:F0:72:E9:BD:05:A5:88:39:D7:11:C6:5A:56:45:BC X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Microsoft Server Gated Crypto, Netscape Server Gated Crypto X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: md5WithRSAEncryption - b7:39:45:27:3a:f2:a3:95:ec:54:bf:5d:c6:69:d9:53:88:5a: - 9d:81:1a:3b:92:90:9d:24:79:2d:36:a4:4e:c2:7e:1c:46:3a: - f8:73:8b:ef:d2:9b:31:1c:ce:8c:6d:96:61:be:c3:09:11:da: - ab:b3:9b:88:13:38:2b:32:d2:e2:59:58:1e:bc:d2:6c:49:5c: - 08:39:84:76:39:66:ff:35:d1:de:fe:43:28:91:e6:10:c8:50: - 72:57:8d:a7:42:32:44:a8:f5:99:7b:41:a1:f4:4e:61:f4:f2: - 2c:94:37:57:75:05:5a:5e:72:f2:5d:5e:45:57:46:7a:91:bd: - 42:51 + 14:5e:87:41:5c:3e:23:69:01:1a:a3:e7:e4:82:f1:98:ee:e0: + 15:49:f7:79:45:46:6d:2d:e5:83:44:9a:c6:ba:c6:26:a5:a8: + 94:95:60:f7:1a:03:f0:45:e2:79:97:96:52:fa:cb:35:f7:89: + 8a:74:5b:08:7e:7e:05:84:a7:17:5a:70:f1:c0:ac:46:a7:c8: + 3a:4d:38:2a:f0:11:b6:cc:63:5c:b0:2a:2a:dd:37:86:f4:b3: + 70:dd:0c:d0:f9:53:59:c7:9d:66:d6:f1:03:7f:a4:63:20:58: + 05:43:78:3c:33:99:bd:9f:a7:5b:bf:64:a6:72:63:f6:02:d0: + ec:d3 -----BEGIN CERTIFICATE----- -MIIC/DCCAmWgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCR1Ix -DzANBgNVBAgTBkF0dGlraTEPMA0GA1UEBxMGQXRoaW5hMQ8wDQYDVQQKEwZHTlVU -TFMxFDASBgNVBAsTC0dOVVRMUyBkZXYuMRcwFQYDVQQDEw5HTlVUTFMgVEVTVCBD -QTEjMCEGCSqGSIb3DQEJARYUZ251dGxzLWRldkBnbnVwZy5vcmcwHhcNMDEwNzA3 -MTAxODQ1WhcNMDIwNzA3MTAxODQ1WjCBiTELMAkGA1UEBhMCR1IxDzANBgNVBAgT -BkF0dGlraTEPMA0GA1UEBxMGQXRoaW5hMQ8wDQYDVQQKEwZHTlVUTFMxFDASBgNV -BAsTC0dOVVRMUyBkZXYuMRIwEAYDVQQDEwlsb2NhbGhvc3QxHTAbBgkqhkiG9w0B -CQEWDnJvb3RAbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQ -C0nrsibZUfXMVwchmd3yh2g9LaGg78yWv/cxZHd8eMOZHpLtpmWE57l7q0vmjVld -IlVX4B5+V7XDXAS0kZSMXEJ61YjYxpiXZJltbUThe2XM/IbztIQt5Vm3MMHeOu8c -4aMor/ijV+upEeH36PwVmOIeS/chdIxYf1DPRhV9lQIDAQABo2cwZTAfBgNVHSME -GDAWgBTv7pSryMpXf1MT23bcGpUAk7rzyTA0BgNVHSUELTArBggrBgEFBQcDAQYI -KwYBBQUHAwIGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAMBgNVHRMBAf8EAjAAMA0G -CSqGSIb3DQEBBAUAA4GBALc5RSc68qOV7FS/XcZp2VOIWp2BGjuSkJ0keS02pE7C -fhxGOvhzi+/SmzEczoxtlmG+wwkR2quzm4gTOCsy0uJZWB680mxJXAg5hHY5Zv81 -0d7+QyiR5hDIUHJXjadCMkSo9Zl7QaH0TmH08iyUN1d1BVpecvJdXkVXRnqRvUJR +MIIDEzCCAnygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBmDELMAkGA1UEBhMCR1Ix +DzANBgNVBAgTBkF0dGlraTEPMA0GA1UEBxMGQXRoaW5hMRcwFQYDVQQKEw5HTlVU +TFMgVEVTVCBDQTEWMBQGA1UECxMNR05VVExTIERFVkVMLjEXMBUGA1UEAxMOR05V +VExTIFRFU1QgQ0ExHTAbBgkqhkiG9w0BCQEWDm5tYXZAaGVsbHVnLmdyMB4XDTAx +MDcyMDA3MTY0NloXDTAyMDcyMDA3MTY0NlowgZwxCzAJBgNVBAYTAkdSMQ8wDQYD +VQQIEwZBdHRpa2kxDzANBgNVBAcTBkF0aGluYTEbMBkGA1UEChMSR05VVExTIEhU +VFAgU0VSVkVSMRswGQYDVQQLExJHTlVUTFMgSFRUUCBTRVJWRVIxEjAQBgNVBAMT +CWxvY2FsaG9zdDEdMBsGCSqGSIb3DQEJARYObm1hdkBoZWxsdWcuZ3IwgZ8wDQYJ +KoZIhvcNAQEBBQADgY0AMIGJAoGBAODDlQtm7L+pH5w09uKPXiKa1P4ae1QTzDmB +wLh+wUMbpPwhM02srBRp2GQEgGEoR73PWGh2hSM8SlrEl3cqnXuTRVubA9N0rtvy +Z/UkDH82gqPwhd634LpyLznvgZijEjKklsc2xVsnDv9+vnFKI16/4O+NE0tnaNO2 +iN+lIXPBAgMBAAGjZzBlMB8GA1UdIwQYMBaAFISQ6A028HLpvQWliDnXEcZaVkW8 +MDQGA1UdJQQtMCsGCCsGAQUFBwMBBggrBgEFBQcDAgYKKwYBBAGCNwoDAwYJYIZI +AYb4QgQBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAFF6HQVw+I2kB +GqPn5ILxmO7gFUn3eUVGbS3lg0SaxrrGJqWolJVg9xoD8EXieZeWUvrLNfeJinRb +CH5+BYSnF1pw8cCsRqfIOk04KvARtsxjXLAqKt03hvSzcN0M0PlTWcedZtbxA3+k +YyBYBUN4PDOZvZ+nW79kpnJj9gLQ7NM= -----END CERTIFICATE----- diff --git a/src/key.pem b/src/key.pem index 885fc9f686..1607a9bdc4 100644 --- a/src/key.pem +++ b/src/key.pem @@ -1,15 +1,15 @@ -----BEGIN RSA PRIVATE KEY----- -MIICXAIBAAKBgQDQC0nrsibZUfXMVwchmd3yh2g9LaGg78yWv/cxZHd8eMOZHpLt -pmWE57l7q0vmjVldIlVX4B5+V7XDXAS0kZSMXEJ61YjYxpiXZJltbUThe2XM/Ibz -tIQt5Vm3MMHeOu8c4aMor/ijV+upEeH36PwVmOIeS/chdIxYf1DPRhV9lQIDAQAB -AoGAG+9oHZ3uWYAH4UhOTNS8WLSV6qEV8uZAMn3UU22KHcyZdxYD5KVTPGVhIpn9 -txeDyF2z1/jgH1bnsTPJ7fUeXPx5uVyuatiFUn5IM+od4OtLQJ5MeRWYQlGdHv/w -XO2TtwekwzkZTtoFvIph7zHqP6pub4UGQ7VrgVSm/syWmIECQQDyOysujmEZ7l4C -C7Tzn+4HmPtGWN1G8ga8XRJuQKagrBoq2oZFfRMC6uCYFPTh+nstRL8WsrnYmzaz -ZQ00NQPfAkEA296lkzP3AdaWXvv4LMrMFlrm2D4p6r01xHcKUHynXyFdJa8vC6F/ -8bpO/Rp20EX6oiDOWd6ue9kyjGB8nOQNCwJAfWXCEgTlIa5zfi2fTGujps08b4t7 -acnLUOIBs4/GcvEFTt/3mKuKFv2OrUxUBVRNRf8LyW1Wplqbs70BW+CCEwJAOWKu -EnKAqKEqVBYtmvs/MyJ8l7n51MOXkfSD46f1QzYBCsHjZIS9UQkQbq0Gj6uEE+a+ -FOSy4643rD3OqGA5KwJBANwtHo4yL3aRK5aIKR6y13/NxY8XrpjX5JIiQzwADCLq -tMVApB6zxFAOzrTnCe0c8kzVxhoVbs28IOFnl/QZ2B8= +MIICXAIBAAKBgQDgw5ULZuy/qR+cNPbij14imtT+GntUE8w5gcC4fsFDG6T8ITNN +rKwUadhkBIBhKEe9z1hodoUjPEpaxJd3Kp17k0VbmwPTdK7b8mf1JAx/NoKj8IXe +t+C6ci8574GYoxIypJbHNsVbJw7/fr5xSiNev+DvjRNLZ2jTtojfpSFzwQIDAQAB +AoGBAMQV/TaYUZ0X1+r4ThbzysVX3M/enI+KQhY9e7u5YbPBL1uDP3XZWbrpaI5B +WxroAEa42MEx/Q7zb07mydl9xSrCPyknoksLQCX6M6mAO7MhYNLmQK75XC9B1XtY +nbaR0mn81V25isrn/NM7UyU0rx94o5wF9sZcIYPPe1eYGeANAkEA+YrYTfBlxfXB +uvfcXwPLaYtFFa2ujBYWcG1qZ0YcZCWGstCLkEE5hLtOSfhuqwP5ID9AGOkQbX9d +547AZgXe4wJBAOaUljpyk4z1Hz0cykHrRAiNhYkVQ7TEFltwDjdp3wezBmJL3Ywx +97QV+BoXKYb0yd73FyG7H+x3dZSF2JORoAsCQCeRtKrnK7wwNAAJvY/zchXSV6oQ +WFUuS3CYaP7nRyk6KhnAp+C/9vbtHITuN942SxKp9Of+TPSP9bv6DtgepjECQCsX +qdvSffDh/qyVLNeU+GoAyOwNpVGrM+Jy1rVUe/Icax0DwKvqyrhFQtDdc01dgjzB +QPl010qCKN9RBGDP3nECQF23yIrdYK7ik8D+985tfM387lEU9KXXI0WC9x04U+bO +ROivdH5QHqM/49WyOPmFRC1SO1EdDd/CrpEv484HFRk= -----END RSA PRIVATE KEY----- diff --git a/src/pkcs1.asn b/src/pkcs1.asn index d76ffc7472..c162b5fd46 100644 --- a/src/pkcs1.asn +++ b/src/pkcs1.asn @@ -45,5 +45,23 @@ OtherPrimeInfo ::= SEQUENCE { coefficient INTEGER -- ti } +-- for signature calculation -nmav + +AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + parameters ANY DEFINED BY algorithm OPTIONAL } + -- contains a value of the type + -- registered for use with the + -- algorithm object identifier value + +DigestInfo ::= SEQUENCE { + digestAlgorithm DigestAlgorithmIdentifier, + digest Digest +} + +DigestAlgorithmIdentifier ::= AlgorithmIdentifier + +Digest ::= OCTET STRING + END
\ No newline at end of file |