aboutsummaryrefslogtreecommitdiffstats
path: root/doc/crypto
diff options
context:
space:
mode:
authorSimon L. B. Nielsen <simon@FreeBSD.org>2008-09-21 14:56:30 +0000
committerSimon L. B. Nielsen <simon@FreeBSD.org>2008-09-21 14:56:30 +0000
commitbb1499d2aac1d25a95b8573ff425751f06f159e1 (patch)
treea136b5b2317abe8eb83b021afe5e088230fd67e2 /doc/crypto
parentee266f1253f9cc49430572463d26f72910dfb49e (diff)
downloadsrc-bb1499d2aac1d25a95b8573ff425751f06f159e1.tar.gz
src-bb1499d2aac1d25a95b8573ff425751f06f159e1.zip
Vendor import of OpenSSL 0.9.8i.vendor/openssl/0.9.8i
Notes
Notes: svn path=/vendor-crypto/openssl/dist/; revision=183234 svn path=/vendor-crypto/openssl/0.9.8i/; revision=193572; tag=vendor/openssl/0.9.8i
Diffstat (limited to 'doc/crypto')
-rw-r--r--doc/crypto/ASN1_generate_nconf.pod35
-rw-r--r--doc/crypto/DH_set_method.pod2
-rw-r--r--doc/crypto/DSA_set_method.pod2
-rw-r--r--doc/crypto/OPENSSL_ia32cap.pod36
-rw-r--r--doc/crypto/RAND_bytes.pod3
-rw-r--r--doc/crypto/RAND_set_rand_method.pod2
-rw-r--r--doc/crypto/RSA_set_method.pod2
-rw-r--r--doc/crypto/X509_NAME_print_ex.pod4
-rw-r--r--doc/crypto/des_modes.pod2
-rw-r--r--doc/crypto/engine.pod6
10 files changed, 57 insertions, 37 deletions
diff --git a/doc/crypto/ASN1_generate_nconf.pod b/doc/crypto/ASN1_generate_nconf.pod
index ba6e3c2e8140..1157cff510d6 100644
--- a/doc/crypto/ASN1_generate_nconf.pod
+++ b/doc/crypto/ASN1_generate_nconf.pod
@@ -28,7 +28,11 @@ The actual data encoded is determined by the string B<str> and
the configuration information. The general format of the string
is:
- B<[modifier,]type[:value]>
+=over 2
+
+=item B<[modifier,]type[:value]>
+
+=back
That is zero or more comma separated modifiers followed by a type
followed by an optional colon and a value. The formats of B<type>,
@@ -81,13 +85,13 @@ the format B<YYYYMMDDHHMMSSZ>.
=item B<OCTETSTRING>, B<OCT>
-Emcodes an ASN1 B<OCTET STRING>. B<value> represents the contents
+Encodes an ASN1 B<OCTET STRING>. B<value> represents the contents
of this structure, the format strings B<ASCII> and B<HEX> can be
used to specify the format of B<value>.
-=item B<BITSRING>, B<BITSTR>
+=item B<BITSTRING>, B<BITSTR>
-Emcodes an ASN1 B<BIT STRING>. B<value> represents the contents
+Encodes an ASN1 B<BIT STRING>. B<value> represents the contents
of this structure, the format strings B<ASCII>, B<HEX> and B<BITLIST>
can be used to specify the format of B<value>.
@@ -147,10 +151,11 @@ bits is set to zero.
This specifies the format of the ultimate value. It should be followed
by a colon and one of the strings B<ASCII>, B<UTF8>, B<HEX> or B<BITLIST>.
-If no format specifier is included then B<ASCII> is used. If B<UTF8> is specified
-then the value string must be a valid B<UTF8> string. For B<HEX> the output must
-be a set of hex digits. B<BITLIST> (which is only valid for a BIT STRING) is a
-comma separated list of set bits.
+If no format specifier is included then B<ASCII> is used. If B<UTF8> is
+specified then the value string must be a valid B<UTF8> string. For B<HEX> the
+output must be a set of hex digits. B<BITLIST> (which is only valid for a BIT
+STRING) is a comma separated list of the indices of the set bits, all other
+bits are zero.
=back
@@ -168,16 +173,20 @@ An IA5String explicitly tagged using APPLICATION tagging:
EXPLICIT:0A,IA5STRING:Hello World
+A BITSTRING with bits 1 and 5 set and all others zero:
+
+ FORMAT=BITLIST,BITSTRING:1,5
+
A more complex example using a config file to produce a
SEQUENCE consiting of a BOOL an OID and a UTF8String:
-asn1 = SEQUENCE:seq_section
+ asn1 = SEQUENCE:seq_section
-[seq_section]
+ [seq_section]
-field1 = BOOLEAN:TRUE
-field2 = OID:commonName
-field3 = UTF8:Third field
+ field1 = BOOLEAN:TRUE
+ field2 = OID:commonName
+ field3 = UTF8:Third field
This example produces an RSAPrivateKey structure, this is the
key contained in the file client.pem in all OpenSSL distributions
diff --git a/doc/crypto/DH_set_method.pod b/doc/crypto/DH_set_method.pod
index 73261fc4675d..d5cdc3be0ce6 100644
--- a/doc/crypto/DH_set_method.pod
+++ b/doc/crypto/DH_set_method.pod
@@ -36,7 +36,7 @@ structures created later. B<NB>: This is true only whilst no ENGINE has been set
as a default for DH, so this function is no longer recommended.
DH_get_default_method() returns a pointer to the current default DH_METHOD.
-However, the meaningfulness of this result is dependant on whether the ENGINE
+However, the meaningfulness of this result is dependent on whether the ENGINE
API is being used, so this function is no longer recommended.
DH_set_method() selects B<meth> to perform all operations using the key B<dh>.
diff --git a/doc/crypto/DSA_set_method.pod b/doc/crypto/DSA_set_method.pod
index bc3cfb1f0a78..9c1434bd8d42 100644
--- a/doc/crypto/DSA_set_method.pod
+++ b/doc/crypto/DSA_set_method.pod
@@ -36,7 +36,7 @@ structures created later. B<NB>: This is true only whilst no ENGINE has
been set as a default for DSA, so this function is no longer recommended.
DSA_get_default_method() returns a pointer to the current default
-DSA_METHOD. However, the meaningfulness of this result is dependant on
+DSA_METHOD. However, the meaningfulness of this result is dependent on
whether the ENGINE API is being used, so this function is no longer
recommended.
diff --git a/doc/crypto/OPENSSL_ia32cap.pod b/doc/crypto/OPENSSL_ia32cap.pod
index 121a8ddee5e1..2e659d34a5c4 100644
--- a/doc/crypto/OPENSSL_ia32cap.pod
+++ b/doc/crypto/OPENSSL_ia32cap.pod
@@ -17,19 +17,27 @@ register after executing CPUID instruction with EAX=1 input value (see
Intel Application Note #241618). Naturally it's meaningful on IA-32[E]
platforms only. The variable is normally set up automatically upon
toolkit initialization, but can be manipulated afterwards to modify
-crypto library behaviour. For the moment of this writing three bits are
-significant, namely bit #28 denoting Hyperthreading, which is used to
-distinguish Intel P4 core, bit #26 denoting SSE2 support, and bit #4
-denoting presence of Time-Stamp Counter. Clearing bit #26 at run-time
-for example disables high-performance SSE2 code present in the crypto
-library. You might have to do this if target OpenSSL application is
-executed on SSE2 capable CPU, but under control of OS which does not
-support SSE2 extentions. Even though you can manipulate the value
-programmatically, you most likely will find it more appropriate to set
-up an environment variable with the same name prior starting target
-application, e.g. 'env OPENSSL_ia32cap=0x10 apps/openssl', to achieve
-same effect without modifying the application source code.
-Alternatively you can reconfigure the toolkit with no-sse2 option and
-recompile.
+crypto library behaviour. For the moment of this writing six bits are
+significant, namely:
+
+1. bit #28 denoting Hyperthreading, which is used to distiguish
+ cores with shared cache;
+2. bit #26 denoting SSE2 support;
+3. bit #25 denoting SSE support;
+4. bit #23 denoting MMX support;
+5. bit #20, reserved by Intel, is used to choose between RC4 code
+ pathes;
+6. bit #4 denoting presence of Time-Stamp Counter.
+
+For example, clearing bit #26 at run-time disables high-performance
+SSE2 code present in the crypto library. You might have to do this if
+target OpenSSL application is executed on SSE2 capable CPU, but under
+control of OS which does not support SSE2 extentions. Even though you
+can manipulate the value programmatically, you most likely will find it
+more appropriate to set up an environment variable with the same name
+prior starting target application, e.g. on Intel P4 processor 'env
+OPENSSL_ia32cap=0x12900010 apps/openssl', to achieve same effect
+without modifying the application source code. Alternatively you can
+reconfigure the toolkit with no-sse2 option and recompile.
=cut
diff --git a/doc/crypto/RAND_bytes.pod b/doc/crypto/RAND_bytes.pod
index ce6329ce54af..1a9b91e28144 100644
--- a/doc/crypto/RAND_bytes.pod
+++ b/doc/crypto/RAND_bytes.pod
@@ -25,6 +25,9 @@ unpredictable. They can be used for non-cryptographic purposes and for
certain purposes in cryptographic protocols, but usually not for key
generation etc.
+The contents of B<buf> is mixed into the entropy pool before retrieving
+the new pseudo-random bytes unless disabled at compile time (see FAQ).
+
=head1 RETURN VALUES
RAND_bytes() returns 1 on success, 0 otherwise. The error code can be
diff --git a/doc/crypto/RAND_set_rand_method.pod b/doc/crypto/RAND_set_rand_method.pod
index c9bb6d9f27b3..e5b780fad06b 100644
--- a/doc/crypto/RAND_set_rand_method.pod
+++ b/doc/crypto/RAND_set_rand_method.pod
@@ -30,7 +30,7 @@ true only whilst no ENGINE has been set as a default for RAND, so this function
is no longer recommended.
RAND_get_default_method() returns a pointer to the current RAND_METHOD.
-However, the meaningfulness of this result is dependant on whether the ENGINE
+However, the meaningfulness of this result is dependent on whether the ENGINE
API is being used, so this function is no longer recommended.
=head1 THE RAND_METHOD STRUCTURE
diff --git a/doc/crypto/RSA_set_method.pod b/doc/crypto/RSA_set_method.pod
index 0a305f6b140d..2c963d7e5bba 100644
--- a/doc/crypto/RSA_set_method.pod
+++ b/doc/crypto/RSA_set_method.pod
@@ -42,7 +42,7 @@ structures created later. B<NB>: This is true only whilst no ENGINE has
been set as a default for RSA, so this function is no longer recommended.
RSA_get_default_method() returns a pointer to the current default
-RSA_METHOD. However, the meaningfulness of this result is dependant on
+RSA_METHOD. However, the meaningfulness of this result is dependent on
whether the ENGINE API is being used, so this function is no longer
recommended.
diff --git a/doc/crypto/X509_NAME_print_ex.pod b/doc/crypto/X509_NAME_print_ex.pod
index 919b90891937..2579a5dc9dc6 100644
--- a/doc/crypto/X509_NAME_print_ex.pod
+++ b/doc/crypto/X509_NAME_print_ex.pod
@@ -86,10 +86,10 @@ is equivalent to:
B<ASN1_STRFLGS_RFC2253 | XN_FLAG_SEP_COMMA_PLUS | XN_FLAG_DN_REV | XN_FLAG_FN_SN | XN_FLAG_DUMP_UNKNOWN_FIELDS>
-B<XN_FLAG_ONELINE> is a more readable one line format it is the same as:
+B<XN_FLAG_ONELINE> is a more readable one line format which is the same as:
B<ASN1_STRFLGS_RFC2253 | ASN1_STRFLGS_ESC_QUOTE | XN_FLAG_SEP_CPLUS_SPC | XN_FLAG_SPC_EQ | XN_FLAG_FN_SN>
-B<XN_FLAG_MULTILINE> is a multiline format is is the same as:
+B<XN_FLAG_MULTILINE> is a multiline format which is the same as:
B<ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_ESC_MSB | XN_FLAG_SEP_MULTILINE | XN_FLAG_SPC_EQ | XN_FLAG_FN_LN | XN_FLAG_FN_ALIGN>
B<XN_FLAG_COMPAT> uses a format identical to X509_NAME_print(): in fact it calls X509_NAME_print() internally.
diff --git a/doc/crypto/des_modes.pod b/doc/crypto/des_modes.pod
index 02664036fc6c..e883ca8fde86 100644
--- a/doc/crypto/des_modes.pod
+++ b/doc/crypto/des_modes.pod
@@ -4,7 +4,7 @@
=head1 NAME
-Modes of DES - the variants of DES and other crypto algorithms of OpenSSL
+des_modes - the variants of DES and other crypto algorithms of OpenSSL
=head1 DESCRIPTION
diff --git a/doc/crypto/engine.pod b/doc/crypto/engine.pod
index 75933fccadc5..f5ab1c3e50fd 100644
--- a/doc/crypto/engine.pod
+++ b/doc/crypto/engine.pod
@@ -183,7 +183,7 @@ Due to the modular nature of the ENGINE API, pointers to ENGINEs need to be
treated as handles - ie. not only as pointers, but also as references to
the underlying ENGINE object. Ie. one should obtain a new reference when
making copies of an ENGINE pointer if the copies will be used (and
-released) independantly.
+released) independently.
ENGINE objects have two levels of reference-counting to match the way in
which the objects are used. At the most basic level, each ENGINE pointer is
@@ -200,7 +200,7 @@ B<functional> reference. This kind of reference can be considered a
specialised form of structural reference, because each functional reference
implicitly contains a structural reference as well - however to avoid
difficult-to-find programming bugs, it is recommended to treat the two
-kinds of reference independantly. If you have a functional reference to an
+kinds of reference independently. If you have a functional reference to an
ENGINE, you have a guarantee that the ENGINE has been initialised ready to
perform cryptographic operations and will remain uninitialised
until after you have released your reference.
@@ -587,7 +587,7 @@ extension).
The ENGINE API and internal architecture is currently being reviewed. Slated for
possible release in 0.9.8 is support for transparent loading of "dynamic"
ENGINEs (built as self-contained shared-libraries). This would allow ENGINE
-implementations to be provided independantly of OpenSSL libraries and/or
+implementations to be provided independently of OpenSSL libraries and/or
OpenSSL-based applications, and would also remove any requirement for
applications to explicitly use the "dynamic" ENGINE to bind to shared-library
implementations.