Re: Need input for Certificate generation
On 16 Nov 2012, at 4:36 AM, Jeffrey Walton noloa...@gmail.com wrote:
On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton noloa...@gmail.com wrote:
On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai pravesh@gmail.com wrote:
CryptGenRandom(hCryptProv, SEED_SIZE, buf); // On Windows OS
apr_generate_random_bytes(buf, SEED_SIZE); // On Linux OS
Speaking of poor documentation…..
Why are you discussing APR on the openssl list? Surely if you had a problem
with the APR documentation this would be a matter for the APR lists instead?
I looked at the header and the source. They are different style
sheets applied to the same file (I expected to see the H file, and
the C file). Neither had comments.
Really?
According to the source code, the header file is here:
https://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/include/apr_general.h
The implementation is platform specific (that's the point of APR), and for unix
it is here:
https://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/misc/unix/rand.c
Both the header and source contain comments.
Confer
http://apr.apache.org/docs/apr/0.9/apr__general_8h-source.html and
http://apr.apache.org/docs/apr/0.9/group__apr__random.html.
Why would you choose the obsolete v0.9 of APR as an example, when the latest
version is v1.4.6? Have you read the documentation at http://apr.apache.org/
that covers this?
I'll reproduce it here without the markup:
apr_status_t apr_generate_random_bytes(
unsigned char * buf,
int length
)
So, there are a few problems here. First is no documentation. Verbum
sapienti sat.
APR uses doxygen as a documentation generation system:
http://en.wikipedia.org/wiki/Doxygen
The documentation is generated from the source headers, for example:
/**
* Generate random bytes.
* @param buf Buffer to fill with random bytes
* @param length Length of buffer in bytes
*/
APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
apr_size_t length);
The phrase generate random bytes is woefully inadequate, so I did the right
thing and raised the issue on the right mailing list, archived here:
http://www.mail-archive.com/dev@apr.apache.org/msg24968.html
Second, you don't know what conditions need to be satisfied to define
APR_HAS_RANDOM (did you even know it was there?). This could be fixed
with documentation, but APR chose otherwise.
If you look closer at APR, you'll notice that to build it, you run the
configure script generated by a tool called autoconf. If you had occasion to
care where APR_HAS_RANDOM came from, you would ensure that you understood
autoconf and how it tests for system capability at compile time. It is not
APR's job to re-document the autoconf tool:
http://en.wikipedia.org/wiki/Autoconf
Third, you don't know what the function returns on success. Is there a
apr_succes? Or apr_true? This could be fixed with documentation, but
APR chose otherwise.
The error codes are documented extensively here:
http://apr.apache.org/docs/apr/1.4/group__apr__errno.html
Fourth, the API tells you a negative length is acceptable. This could
be fixed with documentation, but APR chose otherwise.
Really? The API specifies a length of apr_size_t. If you read the documentation
(Hint: try a google search for site:apr.apache.org apr_size_t) you discover
that apr_size_t is documented here as being equivalent to size_t:
http://apr.apache.org/docs/apr/1.4/group__apr__platform.html
In turn, size_t is defined as an unsigned type, such as unsigned int, depending
on your platform.
By reading the documentation you would have discovered that a negative length
is not possible.
A negative
length makes no sense whatsoever (I know, its not limited to APR). I
would encourage you to write a few negative self-tests and submit it
to the project: send in a NULL`buf`, a zero `length`, and a negative
`length`. See how the library handles it. Since they botched the API
design, I would not be surprised if they SIGABRT on you (that's how
*not* to build a resilient system).
I would suggest instead that you read the documentation.
Fifth, there is probably some internal state, but we don't know that
for sure. This could be fixed with documentation, but APR chose
otherwise. If there is state, you don't know where it came from or its
quality. Did they limit themselves to (1) Time of Day, (2) Mac
address, (3) /dev/{u}rand, (4) the kernel's hwrand, or (5) virtio
gear? Perhaps some other clever combination? Are they constantly
hedging (probably not)? If there is no state, they have already broken
you (that's how *not* to build a resilient system).
Correct, and I have raised this on the d...@apr.apache.org list, just as you
should have done.
This is a bit more personal taste, but I require PRNGs to be thread
safe. So Sixth, is the library thread safe? Is the call to
apr_generate_random_bytes() thread safe? I would definitely write a
Usage of d2i_RSA_PUBKEY function!!
Hi,
I need to load RSA Public key which is stored in the char buffer. I came
across d2i_RSA_PUBKEY function to do the same (Please correct me if I am
wrong here).
When I use this function, RSA Public key is not getting loaded.
In the main, i have the following function call:
loadRSAPubKey(MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0yepYbVklwYuwGEmenQhVwyddHGdM26rZqWG5tFFPYz1QA51EJ44thSejrbRKHqV/EmqU8wwuFeaDmxnVz6UhG3HfjuTbAkkuZ+boEIealr/Ml+kHqRgzQ6G1rP9+5goboZzlpB9b8zYvp+5my5xFCd8OqyoKKyoHBJ3Tf0NCSstow7k0W/5JMeDa844HpCK4rOxlUaIGsDGTC/XIJ93EQs8yT4js5iw++pJslQvh1RzeQtzLQ8xNGYKlr9RyIvh2S28qXb+qfEx7r+kG8RjS4jc3E3XR/nja7HXnAFWCgF/cRcj5aQHq02scW8Vi+iBS/A1Y5RD2QMxJqY1yxC28QIDAQAB);
int loadRSAPubKey(char *key)
{
const unsigned char *p = key;
int keylen = strlen(key);
prsa_loaded = (RSA *)d2i_RSAPublicKey(NULL, p, keylen);
if(!prsa_loaded)
{
printf(Failed to load RSA key\n);
exit(0);
}
return 1;
}
It was always saying Failed to load RSA Key and exiting...
Am i missing something here??
Could you please help me out.
Thank you.
regards
Praveen
--
View this message in context:
http://openssl.6102.n7.nabble.com/Usage-of-d2i-RSA-PUBKEY-function-tp42353.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Usage of d2i_RSA_PUBKEY function!!
On 16 Nov 2012, at 4:37 PM, PraveenPVS meetpraveen...@gmail.com wrote: I need to load RSA Public key which is stored in the char buffer. I came across d2i_RSA_PUBKEY function to do the same (Please correct me if I am wrong here). The d2i in the function you're trying to use means from DER encoded to internal, you'll see a whole lot of complementary functions with i2d in them that do the opposite. The data you've shown looks like it has been PEM encoded, not DER encoded: loadRSAPubKey(MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0yepYbVklwYuwGEmenQhVwyddHGdM26rZqWG5tFFPYz1QA51EJ44thSejrbRKHqV/EmqU8wwuFeaDmxnVz6UhG3HfjuTbAkkuZ+boEIealr/Ml+kHqRgzQ6G1rP9+5goboZzlpB9b8zYvp+5my5xFCd8OqyoKKyoHBJ3Tf0NCSstow7k0W/5JMeDa844HpCK4rOxlUaIGsDGTC/XIJ93EQs8yT4js5iw++pJslQvh1RzeQtzLQ8xNGYKlr9RyIvh2S28qXb+qfEx7r+kG8RjS4jc3E3XR/nja7HXnAFWCgF/cRcj5aQHq02scW8Vi+iBS/A1Y5RD2QMxJqY1yxC28QIDAQAB); To convert the PEM encoding, try wrap your buffer in a BIO and call PEM_read_bio_X509(). man PEM_read_bio_X509 for details. Make sure you preserve the - bars before and after the PEM encoded certificate, as they form part of the PEM encoding and your data may be ignored if you chop them off. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: [openssl-users] Usage of d2i_RSA_PUBKEY function!!
Your RSA public key is not pure DER encoded, it's DER+base64 encoded.
d2i_* functions take pure DER objects (binary on the wire).
--
Erwann ABALEA
-
multicoprothalassotope: station balnéaire de la Méditerranée
Le 16/11/2012 15:37, PraveenPVS a écrit :
Hi,
I need to load RSA Public key which is stored in the char buffer. I came
across d2i_RSA_PUBKEY function to do the same (Please correct me if I am
wrong here).
When I use this function, RSA Public key is not getting loaded.
In the main, i have the following function call:
loadRSAPubKey(MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0yepYbVklwYuwGEmenQhVwyddHGdM26rZqWG5tFFPYz1QA51EJ44thSejrbRKHqV/EmqU8wwuFeaDmxnVz6UhG3HfjuTbAkkuZ+boEIealr/Ml+kHqRgzQ6G1rP9+5goboZzlpB9b8zYvp+5my5xFCd8OqyoKKyoHBJ3Tf0NCSstow7k0W/5JMeDa844HpCK4rOxlUaIGsDGTC/XIJ93EQs8yT4js5iw++pJslQvh1RzeQtzLQ8xNGYKlr9RyIvh2S28qXb+qfEx7r+kG8RjS4jc3E3XR/nja7HXnAFWCgF/cRcj5aQHq02scW8Vi+iBS/A1Y5RD2QMxJqY1yxC28QIDAQAB);
int loadRSAPubKey(char *key)
{
const unsigned char *p = key;
int keylen = strlen(key);
prsa_loaded = (RSA *)d2i_RSAPublicKey(NULL, p, keylen);
if(!prsa_loaded)
{
printf(Failed to load RSA key\n);
exit(0);
}
return 1;
}
It was always saying Failed to load RSA Key and exiting...
Am i missing something here??
Could you please help me out.
Thank you.
regards
Praveen
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Need input for Certificate generation
On Fri, Nov 16, 2012 at 9:17 AM, Graham Leggett minf...@sharp.fm wrote: On 16 Nov 2012, at 4:36 AM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai pravesh@gmail.com wrote: CryptGenRandom(hCryptProv, SEED_SIZE, buf); // On Windows OS apr_generate_random_bytes(buf, SEED_SIZE); // On Linux OS Speaking of poor documentation….. Why are you discussing APR on the openssl list? Surely if you had a problem with the APR documentation this would be a matter for the APR lists instead? Poor documentation was a recent thread on the list. I don't use APR, and I don't care about it. I won't be taking any time to join their mailing list or report bugs. For what its worth, I think its great that you did. I was more concerned with his use of a possibly defective PRNG. That's why I took the time to explain the problems with the PRNG. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Need input for Certificate generation
On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
...
Headless servers, entropy starvation, and rollbacks are a concern in
modern environments. OpenSSL and other entropy gathers, such as EDG,
don't account for the later. Its best to take the bull by the horns
and do it yourself. At minimum, you need to call RAND_add() with
entropy external to /dev/{u}rand.
Would you care to elaborate on the following points:
1. What do you mean by rollback
2. What RNG/PRNG are you referring to as EDG
3. What exactly makes /dev/{u,}random in current (not ancient) Linux
kernelsinsecure given an appropriate supply of entropy?
Note that the two papers you site on the Linux kernel PRNG are:
I. A 6 year old document, presumably not applicable to the code in
currentkernel versions.
II. A document about the consequences of using any PRNG without
sufficiententropy input, with the Linux kernel PRNG as a common
example. This wouldpresumably be irrelevant if feeding the kernel
plenty of external entropy, e.g.by getting it from a hardware RNG
hooked up to a trusted server (under yourown control of cause).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Need input for Certificate generation
Hi Jacob,
On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm jb-open...@wisemo.com wrote:
On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
...
Headless servers, entropy starvation, and rollbacks are a concern in
modern environments. OpenSSL and other entropy gathers, such as EDG,
don't account for the later. Its best to take the bull by the horns
and do it yourself. At minimum, you need to call RAND_add() with
entropy external to /dev/{u}rand.
Would you care to elaborate on the following points:
1. What do you mean by rollback
Virtual Machine rollback attacks.
2. What RNG/PRNG are you referring to as EDG
EDG is Entropy Gatering Daemon. I was talking to John Steven about it
over the summer (John is CTO of Cigital, OWASP member, and part of the
project). EDG does not take measure to mitigate rollback attacks.
3. What exactly makes /dev/{u,}random in current (not ancient) Linux
kernelsinsecure given an appropriate supply of entropy?
Note that the two papers you site on the Linux kernel PRNG are:
I. A 6 year old document, presumably not applicable to the code in
currentkernel versions.
I don't believe this is correct. For example, the Linux generator
still lacks forward secrecy.
II. A document about the consequences of using any PRNG without
sufficient entropy input, with the Linux kernel PRNG as a common
example. This would presumably be irrelevant if feeding the kernel
plenty of external entropy e.g. by getting it from a hardware RNG
hooked up to a trusted server (under your own control of course).
The trusted server is a problem. First some background.
The Linux kernel folks *disabled* feeding data into the generator
based on interrupts because the attacker may control it. For example,
the arrival of a network packet. There's a real problem of starvation,
especially in headless servers and mobile devices. The problem was
highlighted (again) in a recent paper: Mining Your Ps and Qs:
Detection of Widespread Weak Keys in Network Devices,
https://factorable.net/paper.html. See Section 5 where the analysis
occurs and 5.1, Weak entropy and the Linux RNG.
If I go to https://www.wisemo.com, I initiated that connection so its
not under control of an attacker). The exchange contains some random
(but public) data - namely, Wisemo's public key. A passive attacker on
the public internet may be able to observe the exchange. So we can
improve entropy in the generator at the cost of leaking information
about state input.
If the server is within my logical security boundary (for example, my
LAN/MAN segment), the attacker probably cannot observe the exchange.
In this case, I can improve entropy in the generator without the side
effect of leaking information about state input. Later, when the
machine goes out on the internet, its quality of random numbers will
be improved.
You should join us over at the cryptography mailing list
(http://lists.randombit.net/mailman/listinfo/cryptography).
e.g. by getting it from a hardware RNG
I personally use an Entropy Key when I need to ensure I have
sufficient bits to generate a long term key
(http://www.entropykey.co.uk). I carry it with me in my laptop bag.
I know of a number of medium and large size enterprises that don't use
hardware, and rely on the software generator provided by the OS. Those
enterprises include financial institutions in New York.
This is a true story. I'm a security architect, and this got pushed to
the team for risk acceptance. One financial institution was having
problems with entropy depletion in a virtual environment. The
appliance was apparently running out, and could not push sufficient
entropy to its hosts (it was blocking in calls to /dev/random, if I
recall correctly). The vendor stated we should delete /dev/random and
then link it to /dev/urandom (or vice versa), so the generator would
not block.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Usage of d2i_RSA_PUBKEY function!!
From: owner-openssl-us...@openssl.org On Behalf Of Graham Leggett Sent: Friday, 16 November, 2012 10:08 To: openssl-users@openssl.org Subject: Re: Usage of d2i_RSA_PUBKEY function!! On 16 Nov 2012, at 4:37 PM, PraveenPVS meetpraveen...@gmail.com wrote: I need to load RSA Public key which is stored in the char buffer. I came across d2i_RSA_PUBKEY function to do the same (Please correct me if I am wrong here). The d2i in the function you're trying to use means from DER encoded to internal, you'll see a whole lot of complementary functions with i2d in them that do the opposite. The data you've shown looks like it has been PEM encoded, not DER encoded: loadRSAPubKey(MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ye pYbVklwYuwGEmenQhVwyddHGdM26rZqWG5tFFPYz1QA51EJ44thSejrbRKHqV/ EmqU8wwuFeaDmxnVz6UhG3HfjuTbAkkuZ+boEIealr/Ml+kHqRgzQ6G1rP9+5g oboZzlpB9b8zYvp+ 5my5xFCd8OqyoKKyoHBJ3Tf0NCSstow7k0W/5JMeDa844HpCK4rOxlUaIGsDGT C/XIJ93EQs8yT4js5iw++pJslQvh1RzeQtzLQ8xNGYKlr9RyIvh2S28qXb+qfE x7r+kG8RjS4jc3E3XR/nja7HXnAFWCgF/cRcj5aQHq02scW8Vi+iBS/A1Y5RD2 QMxJqY1yxC28QIDAQAB); To convert the PEM encoding, try wrap your buffer in a BIO and call PEM_read_bio_X509(). man PEM_read_bio_X509 for details. Make sure you preserve the - bars before and after the PEM encoded certificate, as they form part of the PEM encoding and your data may be ignored if you chop them off. Those need to be dashes-BEGIN and END *lines* before and after, and you also must keep line breaks in the body. b64BIO by default rejects base64 lines longer than the traditional PEM/MIME limit (somewhere around 76-80, I don't remember exactly). For an explicit b64BIO you can control this, but not within PEM_read*. Alternatively, convert the base64 to binary (EVP_DecodeBlock *doesn't* enforce the line length limit) and use d2i_*. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
