Question

300分悬赏:谁知道SSL3.0的运算程序?

本人涉及到一个运算SSL3.0的程序问题,但本人对这个名词以及它的含义一无所知,只知道必须要通过这个运算方式才能得到结果,并且含糊的知道要用这个程序的128位算法才能算出结果.高手指点一下本人,应该如何才能或者它的计算方式和计算方式演示程序.市场上是否有相关的演算资料可以购买?
先付出100分,印证了该算法是正确的,另付200.
老班长的意见我都在网页上看到了,但我想要的是他的演算方式你的回答没有涉及到,能否再帮我一把,把演算方式详细的陈列出来呢?感谢!

Answer 1

SSL 的英文全称是 “Secure Sockets Layer” ，中文名为 “ 安全套接层协议层 ” ，它是网景（ Netscape ）公司提出的基于 WEB 应用的安全协议。 SSL 协议指定了一种在应用程序协议（如 HTTP 、 Telenet 、 NMTP 和 FTP 等）和 TCP/IP 协议之间提供数据安全性分层的机制，它为 TCP/IP 连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证。
VPN SSL 200 设备网关适合应用于中小企业规模，满足其企业移动用户、分支机构、供应商、合作伙伴等企业资源（如基于 Web 的应用、企业邮件系统、文件服务器、 C/S 应用系统等）安全接入服务。企业利用自身的网络平台，创建一个增强安全性的企业私有网络。 SSL VPN 客户端的应用是基于标准 Web 浏览器内置的加密套件与服务器协议出相应的加密方法，即经过授权用户只要能上网就能够通过浏览器接入服务器建立 SSL 安全隧道。
SSL VPN 利用三种客户端接入方式来协助用户在任何地方任何时间安全第访问公司的任何资源：

◇ 远程桌面共享

◇ Web Browser 基于浏览器的接入 ( 可以访问 Web 应用程序和文件共享 )

◇ 即时下载的 Java 小应用程序 ( 可访问客户 / 服务器应用程序 )

应用领域：

SSL VPN 提供下述情况的解决方案：企业需要通过互联网（笔记本型计算机、移动个人计算机、远程用户接入）达到广泛而全面性的信息存取。 SSL VPN 能满足所有你的远程接入需要。 SSL VPN 技术为你提供增强的灵活性，以便更好地配合你公司的安全性和基础结构需要，同时给你的用户一个统一的、容易的界面和一个简化的用户经验。 SSL VPN0 还提供了高可用性，它具有可靠的冗余能力，排除了单点故障的可能性，减少系统停机时间，另外它还具有负载均衡的能力，提高系统的整体性能。

ssl2 只是一个版本 还有ssl3
具体去这看看http://www.cqvip.com/qk/92897X/200602/21306411.html

Transport Layer Security Working Group Alan O. Freier
INTERNET-DRAFT Netscape Communications
Expire in six months Philip Karlton
Netscape Communications
Paul C. Kocher
Independent Consultant
November 18, 1996

The SSL Protocol
Version 3.0

<draft-freier-ssl-version3-02.txt>
Status of this memo
This document is an Internet-Draft. 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 made obsolete 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.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document specifies Version 3.0 of the Secure Sockets Layer
(SSL V3.0) protocol, a security protocol that provides
communications privacy over the Internet. The protocol allows
client/server applications to communicate in a way that is designed
to prevent eavesdropping, tampering, or message forgery.

Transport Layer Security Working Group Alan O. Freier
INTERNET-DRAFT Netscape Communications
Expire in six months Philip Karlton
Netscape Communications
Paul C. Kocher
Independent Consultant
November 18, 1996

The SSL Protocol
Version 3.0

<draft-freier-ssl-version3-02.txt>

Status of this memo

This document is an Internet-Draft. 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 made obsolete 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.

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).

Abstract

This document specifies Version 3.0 of the Secure Sockets Layer
(SSL V3.0) protocol, a security protocol that provides
communications privacy over the Internet. The protocol allows
client/server applications to communicate in a way that is designed
to prevent eavesdropping, tampering, or message forgery.

Freier, Karlton, Kocher [Page 1]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

Table of Contents
Status of this memo 1
Abstract 1
Table of Contents 2
1. Introduction 4
2. Goals 4
3. Goals of this document 5
4. Presentation language 5
4.1 Basic block size 5
4.2 Miscellaneous 6
4.3 Vectors 6
4.4 Numbers 7
4.5 Enumerateds 7
4.6 Constructed types 8
4.6.1 Variants 8
4.7 Cryptographic attributes 9
4.8 Constants 10
5. SSL protocol 10
5.1 Session and connection states 10
5.2 Record layer 12
5.2.1 Fragmentation 12
5.2.2 Record compression and decompression 13
5.2.3 Record payload protection and the CipherSpec 13
5.2.3.1 Null or standard stream cipher 14
5.2.3.2 CBC block cipher 15
5.3 Change cipher spec protocol 16
5.4 Alert protocol 16
5.4.1 Closure alerts 17
5.4.2 Error alerts 17
5.5 Handshake protocol overview 18
5.6 Handshake protocol 20
5.6.1 Hello messages 21
5.6.1.1 Hello request 21
5.6.1.2 Client hello 21
5.6.1.3 Server hello 24
5.6.2 Server certificate 25
5.6.3 Server key exchange message 25
5.6.4 Certificate request 27
5.6.5 Server hello done 27
5.6.6 Client certificate 28
5.6.7 Client key exchange message 28
5.6.7.1 RSA encrypted premaster secret message 28
5.6.7.2 FORTEZZA key exchange message 29
5.6.7.3 Client Diffie-Hellman public value 30
5.6.8 Certificate verify 30
5.6.9 Finished 31
5.7 Application data protocol 32
6. Cryptographic computations 32
6.1 Asymmetric cryptographic computations 32
6.1.1 RSA 32
6.1.2 Diffie-Hellman 33
6.1.3 FORTEZZA 33

Freier, Karlton, Kocher [Page 2]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

6.2 Symmetric cryptographic calculations and the CipherSpec 33
6.2.1 The master secret 33
6.2.2 Converting the master secret into keys and MAC 33
6.2.2.1 Export key generation example 35
A. Protocol constant values 36
A.1 Reserved port assignments 36
A.1.1 Record layer 36
A.2 Change cipher specs message 37
A.3 Alert messages 37
A.4 Handshake protocol 37
A.4.1 Hello messages 38
A.4.2 Server authentication and key exchange messages 39
A.5 Client authentication and key exchange messages 40
A.5.1 Handshake finalization message 41
A.6 The CipherSuite 41
A.7 The CipherSpec 42
B. Glossary 44
C. CipherSuite definitions 47
D. Implementation Notes 49
D.1 Temporary RSA keys 49
D.2 Random Number Generation and Seeding 49
D.3 Certificates and authentication 50
D.4 CipherSuites 50
D.5 FORTEZZA 50
D.5.1 Notes on use of FORTEZZA hardware 50
D.5.2 FORTEZZA Ciphersuites 51
D.5.3 FORTEZZA Session resumption 51
E. Version 2.0 Backward Compatibility 52
E.1 Version 2 client hello 52
E.2 Avoiding man-in-the-middle version rollback 53
F. Security analysis 55
F.1 Handshake protocol 55
F.1.1 Authentication and key exchange 55
F.1.1.1 Anonymous key exchange 55
F.1.1.2 RSA key exchange and authentication 56
F.1.1.3 Diffie-Hellman key exchange with authentication 57
F.1.1.4 FORTEZZA 57
F.1.2 Version rollback attacks 57
F.1.3 Detecting attacks against the handshake protocol 58
F.1.4 Resuming sessions 58
F.1.5 MD5 and SHA 58
F.2 Protecting application data 59
F.3 Final notes 59
G. Patent Statement 60
References 61
Authors 62

Freier, Karlton, Kocher [Page 3]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

1. Introduction

The primary goal of the SSL Protocol is to provide privacy and
reliability between two communicating applications. The protocol
is composed of two layers. At the lowest level, layered on top of
some reliable transport protocol (e.g., TCP[TCP]), is the SSL
Record Protocol. The SSL Record Protocol is used for encapsulation
of various higher level protocols. One such encapsulated protocol,
the SSL Handshake Protocol, allows the server and client to
authenticate each other and to negotiate an encryption algorithm
and cryptographic keys before the application protocol transmits or
receives its first byte of data. One advantage of SSL is that it
is application protocol independent. A higher level protocol can
layer on top of the SSL Protocol transparently. The SSL protocol
provides connection security that has three basic properties:

- The connection is private. Encryption is used after an
initial handshake to define a secret key. Symmetric
cryptography is used for data encryption (e.g., DES[DES],
RC4[RC4], etc.)
- The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
- The connection is reliable. Message transport includes a
message integrity check using a keyed MAC. Secure hash
functions (e.g., SHA, MD5, etc.) are used for MAC
computations.

2. Goals

The goals of SSL Protocol v3.0, in order of their priority,
are:
1. Cryptographic security
SSL should be used to establish a secure
connection between two parties.
2. Interoperability
Independent programmers should be able to
develop applications utilizing SSL 3.0 that
will then be able to successfully exchange
cryptographic parameters without knowledge of
one another's code.

Note: It is not the case that all instances of SSL (even
in the same application domain) will be able to
successfully connect. For instance, if the server
supports a particular hardware token, and the client
does not have access to such a token, then the
connection will not succeed.

3. Extensibility SSL seeks to provide a framework into which new
public key and bulk encryption methods can be
incorporated as necessary. This will also
accomplish two sub-goals: to prevent the need

Freier, Karlton, Kocher [Page 4]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

to create a new protocol (and risking the
introduction of possible new weaknesses) and to
avoid the need to implement an entire new
security library.
4. Relative efficiency
Cryptographic operations tend to be highly CPU
intensive, particularly public key operations.
For this reason, the SSL protocol has
incorporated an optional session caching scheme
to reduce the number of connections that need
to be established from scratch. Additionally,
care has been taken to reduce network activity.

3. Goals of this document

The SSL Protocol Version 3.0 Specification is intended primarily
for readers who will be implementing the protocol and those doing
cryptographic analysis of it. The spec has been written with this
in mind, and it is intended to reflect the needs of those two
groups. For that reason, many of the algorithm-dependent data
structures and rules are included in the body of the text (as
opposed to in an Appendix), providing easier access to them.

This document is not intended to supply any details of service
definition nor interface definition, although it does cover select
areas of policy as they are required for the maintenance of solid
security.

4. Presentation language

This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels.
The purpose of this presentation language is to document SSL only,
not to have general application beyond that particular goal.

4.1 Basic block size

The representation of all data items is explicitly specified. The
basic data block size is one byte (i.e. 8 bits). Multiple byte
data items are concatenations of bytes, from left to right, from
top to bottom. From the bytestream a multi-byte item (a numeric in
the example) is formed (using C notation) by:

value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
| byte[n-1];

This byte ordering for multi-byte values is the commonplace network
byte order or big endian format.

Freier, Karlton, Kocher [Page 5]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

4.2 Miscellaneous

Comments begin with "/*" and end with "*/".
Optional components are denoted by enclosing them in "[[ ]]" double
brackets.
Single byte entities containing uninterpreted data are of type
opaque.

4.3 Vectors

A vector (single dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case the length
declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type T' that is a fixed
length vector of type T is

T T'[n];

Here T' occupies n bytes in the data stream, where n is a multiple
of the size of T. The length of the vector is not included in the
encoded stream.

In the following example, Datum is defined to be three consecutive
bytes that the protocol does not interpret, while Data is three
consecutive Datum, consuming a total of nine bytes.

opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */

Variable length vectors are defined by specifying a subrange of
legal lengths, inclusively, using the notation <floor..ceiling>.
When encoded, the actual length precedes the vector's contents in
the byte stream. The length will be in the form of a number
consuming as many bytes as required to hold the vector's specified
maximum (ceiling) length. A variable length vector with an actual
length field of zero is referred to as an empty vector.

T T'<floor..ceiling>;

In the following example, mandatory is a vector that must contain
between 300 and 400 bytes of type opaque. It can never be empty.
The actual length field consumes two bytes, a uint16, sufficient to
represent the value 400 (see Section 4.4). On the other hand,
longer can represent up to 800 bytes of data, or 400 uint16
elements, and it may be empty. Its encoding will include a two
byte actual length field prepended to the vector.

opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */

Freier, Karlton, Kocher [Page 6]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

4.4 Numbers

The basic numeric data type is an unsigned byte (uint8). All
larger numeric data types are formed from fixed length series of
bytes concatenated as described in Section 4.1 and are also
unsigned. The following numeric types are predefined.

uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];

4.5 Enumerateds

An additional sparse data type is available called enum. A field
of type enum can only assume the values declared in the definition.
Each definition is a different type. Only enumerateds of the same
type may be assigned or compared. Every element of an enumerated
must be assigned a value, as demonstrated in the following example.
Since the elements of the enumerated are not ordered, they can be
assigned any unique value, in any order.

enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te;

Enumerateds occupy as much space in the byte stream as would its
maximal defined ordinal value. The following definition would
cause one byte to be used to carry fields of type Color.

enum { red(3), blue(5), white(7) } Color;

One may optionally specify a value without its associated tag to
force the width definition without defining a superfluous element.
In the following example, Taste will consume two bytes in the data
stream but can only assume the values 1, 2 or 4.

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

The names of the elements of an enumeration are scoped within the
defined type. In the first example, a fully qualified reference to
the second element of the enumeration would be Color.blue. Such
qualification is not required if the target of the assignment is
well specified.

Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */

For enumerateds that are never converted to external
representation, the numerical information may be omitted.

enum { low, medium, high } Amount;

Freier, Karlton, Kocher [Page 7]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

4.6 Constructed types

Structure types may be constructed from primitive types for
convenience. Each specification declares a new, unique type. The
syntax for definition is much like that of C.

struct {
T1 f1;
T2 f2;
...
Tn fn;
} [[T]];

The fields within a structure may be qualified using the type's
name using a syntax much like that available for enumerateds. For
example, T.f2 refers to the second field of the previous
declaration. Structure definitions may be embedded.

4.6.1 Variants

Defined structures may have variants based on some knowledge that
is available within the environment. The selector must be an
enumerated type that defines the possible variants the structure
defines. There must be a case arm for every element of the
enumeration declared in the select. The body of the variant
structure may be given a label for reference. The mechanism by
which the variant is selected at runtime is not prescribed by the
presentation language.

struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];

For example

enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;

Freier, Karlton, Kocher [Page 8]
.

INTERNET-DRAFT SSL 3.0 November 18, 1996

struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */
case orange: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;

Variant structures may be qualified (narrowed) by specifying a
value for the selector prior to the type. For example, a

orange VariantRecord

is a narrowed type of a VariantRecord containing a variant_body of
type V2.

4.7 Cryptographic attributes

The four cryptographic operations digital signing, stream cipher
encryption, block cipher encryption, and public key encryption are
designated digitally-signed, stream-ciphered, block-ciphered, and
public-key-encrypted, respectively. A field's cryptographic
processing is specified by prepending an appropriate key word
designation before the field's type specification. Cryptographic
keys are implied by the current session state (see Section 5.1).

In digital signing, one-way hash functions are used as input for a
signing algorithm. In RSA signing, a 36-byte structure of two
hashes (one SHA and one MD5) is signed (encrypted with the private
key). In DSS, the 20 bytes of the SHA hash are run directly
through the Digital Signing Algorithm with no additional hashing.

In stream cipher encryption, the plaintext is exclusive-ORed with
an identical amount of output generated from a
cryptographically-secure keyed pseudorandom number generator.

In block cipher encryption, every block of plaintext encrypts to a
block of ciphertext. Because it is unlikely that the plaintext
(whatever data is to be sent) will break neatly into the necessary
block size (usually 64 bits), it is necessary to pad out the end of
short blocks with some regular pattern, usually all zeroes.

In public key encryption, one-way functions with secret "trapdoors"
are used to encrypt the outgoing data. Data encrypted with the
public key of a given key pair can only be decrypted with the
priva

Answer 2

http://www.openssl.org/
openssl超强的东东,多数ssl的相关产品都是用这个的