SSL_connect( ) want read
Hello, I have got a SSL_ERROR_WANT_READ after a call to SSL_connect. I 'd like to know what should I do exactly ? Thanks
Re: BN_mod_mul_montgomery() causing cpu spike
Thanks Steve. This happened on a system with Intel dual core 2.4ghz processor and 2gig ram. Is the observed cpu pattern expected on such platforms? You mentioned it will be less painful after upcoming validation. Do you mean change in implementation for speedier self-tests? Thanks, Prakash - Original Message - From: Steve Marquess marqu...@opensslfoundation.com To: openssl-users@openssl.org Sent: Thursday, March 03, 2011 1:44 AM Subject: Re: BN_mod_mul_montgomery() causing cpu spike prakgen wrote: Hi, I've enabled fips in sshd (OpenSSH 5.5p1) and linked it against openssl-fips-1.2. Everytime time sshd is spawned, the cpu utilization shoots up and remains high (40% to 90%) for around 5 seconds. By taking backtraces at time intervals (please see below), I found that, during this entire 5 sec period, sshd was executing BN_mod_mul_montgomery() function. Is this expected? Is there a workaround to avoid cpu spike? This is adding delay to ssh login. You are seeing the POST (Power Up Self Test) mandated by FIPS 140-2. It is a huge performance hit on low powered platforms (sometimes taking tens or even hundreds of seconds). We're going to make it significantly less painful for the upcoming new validation now in progress, but there will always be a performance hit relative to the same software without enabling FIPS mode. -Steve M. -- Steve Marquess The OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS compliance question regarding openssl distributions
Hello openssl-users: I asked on the FreeBSD security list but perhaps this one is more apropos. Our company has been tasked to ship a FIPS compliant version of openssl on top of our FreeBSD based product. I am confused on what distribution I am allowed to use to create a FIPS compliant release. Here is what I don't understand after reading the FIPS 140-2 User Guide: In the example of building the openssl FIPS *capable* distribution, it seems one should take the distribution from the official openssl.org/source website and validate it using PGP. However, FreeBSD ships openssl distribution within its source tree. There is no tarball of openssl that I can validate it against. The source is already integrated in the official FreeBSD source trees. However, its based on the openssl distribution found in the official repos. I have not done a complete diff, but there maybe small build changes to incorporate the openssl distribution into the FreeBSD *world* build. So, can I build a FIPS compliant product using the FreeBSD openssl distribution OR do I need to build the official openssl distribution tarball (a la ports)? If this has been answered before, I apologize. Some basic Googling got me mixed answers Thanks! -aps __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Tips on TXT_DB
Hello I recently discovered that openssl has a sort of database (called txt_db) which looks like its a disk-based hash table (like Berkeley DB). It is used in CA to store certificates and stuff, so it should be quite potent. I would like to use it for my own purposes, The api are few, but they look cryptic and feels like they require user to keep track of all the row/column thingy. Any tips/ links on making it work?? Thanks Eugene
RE: SSL - Weak Encryption Test
From: owner-openssl-us...@openssl.org On Behalf Of Nouefel Sent: Tuesday, 01 March, 2011 21:26 Answering your questions: Are you even sure HOSTNAME:443 and HOSTNAME:8000 are the same host? Yes . Its a device . 2. 443 is disabled , Hence it disconnects. What you posted is a failure to connect (timeout). That's not the same thing as a disconnect. It is *a* reasonable thing to do for 'disabled' (though I don't think the best; I prefer to explicitly refuse). 3. 8000 is the port we used to communicate. I need to make sure device does not support weak security. Hence , I ran the openssl commands where for 8000 it connected and writeErr . And you don't know why. Try -msg or -debug as I said, that should at least narrow it down. If you have (other) access to the device, does it have relevant log information? But even if it rejects one particular weak handshake, that doesn't prove it will reject all. And even if it uses only strong ciphersuite(s), there are other ways for security to be weak or fail. Many other ways. You can prove it is capable of supporting strong crypto, which may or may not be strong security. You can't prove it doesn't support weak security, except by inspection. (And even then, if there are bugs/flaws the vendor missed, an outside examiner may not catch them either.) 4. when you say weak algorithm , We are using SSLV3 ciphers used SSL_RSA_WITH_RC4_128_SHA. Your posted cases don't show that, but if you are, that's usually good enough assuming RSA = 1024 bits, which isn't enforced by the protocol or by openssl; some people prefer the safety margin of 1536 or 2048. It's not the only good choice; there are many others. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Command Line Question: req for keypair
From: owner-openssl-us...@openssl.org On Behalf Of Bob Bell (rtbell) Sent: Wednesday, 02 March, 2011 13:33 I am trying to generate a PKCS#10 certificate request with a pre-existing RSA public/private key pair that was generated using genpkey. The actual command is openssl genpkey -out Keys.bin -outform DER -algorithm rsa -pkeyopt rsa_keygen_bits:2048 Could someone please provide me with information on how to do this? Sorry for the relatively newby question, but I have tried to dig it out of the documentation without success. 'man req' if on Unix and you're using the installed openssl (or you adjust MANPATH or equivalent to another copy). It's about 10 screens so I'm not going to copy it here. 'openssl req -?' (hyphen question) for a brief summary. This utility can display/modify an existing CSR, OR create a new one for either an existing keypair or a new keypair, OR create a selfsigned cert from a CSR or directly from a keypair. (Since you want a request, you presumably don't want selfsigned.) For your case do 'openssl req -new -key Keys.bin -keyform DER' and: - use the standard config file (or a copy) and be prompted for the DN fields, and 'extra' attributes (not usually needed); - use a modified config file that sets these fields; or - add -subj to enter (only) the DN fields exactly right PS- According to my network monitor, the CRL fetched from Comodo to validate your email signing cert is nearly a megabyte! Yowza! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Base64 Encoding and Decoding error
From: owner-openssl-us...@openssl.org On Behalf Of Vinay Kumar L
Sent: Tuesday, 01 March, 2011 23:42
Thanks for your reply, but OpenSSL Base64 decoding api returns NULL
on passing Base64 encoded data. The code snippet is as follows:
I very much doubt it returns NULL. NULL in C is a null POINTER
(pedantically, a null pointer CONSTANT). Your code will return
a string of zero characters, i.e. an empty string.
In general this is sometimes called a null STRING but in C
that's confusing because a null string is not a null pointer.
(And FWIW in SQL a NULL value is not an empty string either,
although some user tools will DISPLAY it as such.)
Also, the byte that terminates a C (narrow) string is a null
character or null byte, sometimes called NUL (note 3 letters).
But this character is not IN the string, it is AFTER the string.
int main(int argc, char **argv)
{
char *output = unbase64(dGVzdGVuY29kaW5nCg==,
strlen(dGVzdGVuY29kaW5nCg==));
Your real problem is that the ENCODING should have terminating newline.
See below. (The encoded/decoded DATA can include a newline or not,
which as you have already seen changes the encoding, but often
isn't even characters so the concept of newline doesn't apply.)
printf(Unbase64: %s\n, output);
free(output);
}
In C99 or C++ you must have at least a declaration of the function
before the call. (You can have the definition which is also a
declaration, by arranging your code 'bottom up'.)
But in C89, the implicit declaration is 'returns int'. You should
be unable to assign it to a char* without at least a warning.
And even if you add a cast, it still won't work on some systems
because the calling sequence is actually different. (Pedantically,
initialization isn't assignment but it's sufficiently like.)
In C (both C89 and C99) you can choose whether to use a prototype
declaration (with parameter types) or a nonprototype aka KR1
declaration without. Prototypes are Better(tm).
char *unbase64(unsigned char *input, int length)
With a nonprototype (including implicit) declaration this is wrong.
strlen() returns size_t, not int. On SOME systems size_t and int are
actually the same size (and passed compatibly) and this 'accidentally'
works. On some systems it doesn't work at all. (With a prototype
it will be converted as long as the value is in range. If you have
data long enough its length fits in size_t but not int, use size_t.)
Technically unsigned-char* is not the same type as plain-char*,
which is the value of the string literal above -- even on systems
where plain-char is unsigned. In practice this will always work.
However, since (valid) b64 data is always in a limited character set
that is a subset of the 'basic execution' set, it usually makes sense
to store it in array of plain-char, and pass it as pointer to same.
OTOH the data encoded into and decoded from b64 is often binary
(although your example isn't) so in general treating it as
array of and pointer to unsigned-char is usually better.
{
BIO *b64, *bmem;
char *buffer = (char *)malloc(length);
Should check for failed allocation (returned null pointer) before using,
but I'll assume this is only test/example code. The cast is not needed
in C if you have #include'd stdlib.h as required; without that correct
declaration the cast doesn't actually solve the problem on some systems,
it just silences the warning because you lied to the compiler.
In C++ the cast is needed if you use malloc but you shouldn't use malloc.
memset(buffer, 0, length);
Don't need this if you add just one null terminator in the right place.
If you actually do need zero-fill, calloc() may be less inefficient.
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new_mem_buf(input, length);
bmem = BIO_push(b64, bmem);
BIO_read(bmem, buffer, length);
You should use the return value of BIO_read.
For the data above, the return value is zero, because by default
b64BIO requires input to have the line terminators specified
by PEM (always at the end, plus in the middle if 'too long')
and similarly inserts them on output (which you don't have here).
You can change this with
BIO_set_flags (b64,BIO_FLAGS_BASE64_NO_NL)
When successful, the return value is the number of bytes decoded,
which is convenient for a number of things; in your case you want
to treat the data as a null-terminated string, so that's the
right place to insert a single null-character terminator.
BIO_free_all(bmem);
return buffer;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager
RE: Re:Re: How to retrieve error about private key loading.
From: owner-openssl-us...@openssl.org On Behalf Of ikuzar Sent: Friday, 25 February, 2011 09:57 2011/2/25 lzyzizi lzyz...@126.com You can use ERR_GET_FUNC(l) with the error code to get the error function ID that is defined in the module's header(here is ssl.h). You can also use const char *ERR_func_error_string(unsigned long e) with the error code to get the string representation of the error function. That's just the function-name which is rarely sufficient. While you can fiddle the pieces yourself, ERR_error_string[_n](e,buf[,n]) gives you everything in one lump which is usually more convenient. Or just printf %lx, and lookup manually with commandline 'errstr'. Every time you want to know the string information of the error code, you need to call the void ERR_load_ERR_strings(void) first. (or call ERR_load_(MODULE NAM)_strings(void) such as void ERR_load_SSL_strings(void)) Not 'every time'. You need to load error strings sometime before you use them, but it's common to do it once at startup. ERR_load_ERR_strings only loads some internal infrastructure stuff, which is nowhere near enough. If you want you can do each relevant module individually ERR_load_RSA_strings ERR_load_BN_strings ERR_load_SSL_strings etc., but it's almost always easier to just do SSL_load_error_strings which does everything. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Base64 Encoding and Decoding error
From: Dave Thompson Sent: Thursday, March 03, 2011 10:35 PM To: openssl-users@openssl.org Also, the byte that terminates a C (narrow) string is a null character or null byte, sometimes called NUL (note 3 letters). But this character is not IN the string, it is AFTER the string. If we're being pedantic, the null character is part of the string as far as C is concerned.__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
