summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard Levitte <levitte@openssl.org>2004-07-12 12:49:29 +0000
committerRichard Levitte <levitte@openssl.org>2004-07-12 12:49:29 +0000
commit2f81b64db8354256919d128aecf368a17b27f8d2 (patch)
tree313afd8973e4b5cfa80c9404e78d2ceaee31752f
parent3001755d45a9a0906031986530aba93a0337de7e (diff)
Recent changes from 0.9.6-stable.OpenSSL-engine-0_9_6-stable
-rw-r--r--README16
-rw-r--r--doc/crypto/BN_num_bytes.pod26
2 files changed, 34 insertions, 8 deletions
diff --git a/README b/README
index eeb88d92e8..792e74288d 100644
--- a/README
+++ b/README
@@ -173,11 +173,17 @@
textual explanation of what your patch does.
Note: For legal reasons, contributions from the US can be accepted only
- if a TSA notification and a copy of the patch is sent to crypt@bis.doc.gov;
- see http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic]
- and http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e)).
-
- The preferred format for changes is "diff -u" output. You might
+ if a TSU notification and a copy of the patch are sent to crypt@bis.doc.gov
+ (formerly BXA) with a copy to the ENC Encryption Request Coordinator;
+ please take some time to look at
+ http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic]
+ and
+ http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e))
+ for the details. If "your encryption source code is too large to serve as
+ an email attachment", they are glad to receive it by fax instead; hope you
+ have a cheap long-distance plan.
+
+ Our preferred format for changes is "diff -u" output. You might
generate it like this:
# cd openssl-work
diff --git a/doc/crypto/BN_num_bytes.pod b/doc/crypto/BN_num_bytes.pod
index 61589fb9ac..a6a2e3f819 100644
--- a/doc/crypto/BN_num_bytes.pod
+++ b/doc/crypto/BN_num_bytes.pod
@@ -16,8 +16,14 @@ BN_num_bits, BN_num_bytes, BN_num_bits_word - get BIGNUM size
=head1 DESCRIPTION
-These functions return the size of a B<BIGNUM> in bytes or bits,
-and the size of an unsigned integer in bits.
+BN_num_bytes() returns the size of a B<BIGNUM> in bytes.
+
+BN_num_bits_word() returns the number of significant bits in a word.
+If we take 0x00000432 as an example, it returns 11, not 16, not 32.
+Basically, except for a zero, it returns I<floor(log2(w))+1>.
+
+BN_num_bits() returns the number of significant bits in a B<BIGNUM>,
+following the same principle as BN_num_bits_word().
BN_num_bytes() is a macro.
@@ -25,9 +31,23 @@ BN_num_bytes() is a macro.
The size.
+=head1 NOTES
+
+Some have tried using BN_num_bits() on individual numbers in RSA keys,
+DH keys and DSA keys, and found that they don't always come up with
+the number of bits they expected (something like 512, 1024, 2048,
+...). This is because generating a number with some specific number
+of bits doesn't always set the highest bits, thereby making the number
+of I<significant> bits a little lower. If you want to know the "key
+size" of such a key, either use functions like RSA_size(), DH_size()
+and DSA_size(), or use BN_num_bytes() and multiply with 8 (although
+there's no real guarantee that will match the "key size", just a lot
+more probability).
+
=head1 SEE ALSO
-L<bn(3)|bn(3)>
+L<bn(3)|bn(3)>, L<DH_size(3)|DH_size(3)>, L<DSA_size(3)|DSA_size(3)>,
+L<RSA_size(3)|RSA_size(3)>
=head1 HISTORY