Using OpenSSL cryptographic functions in a multi-threaded application

[wang yanbo]

Hi:
 We are using only the OpenSSL cryptographic functionality, the EVP and
HMAC functions, in a multi-threaded application. Do we need to do
anything to ensure thread safety ? The documentation mentions
CRYPTO_set_locking_callback() and CRYPTO_set_id_callback() ,but we are
not calling these functions nor have we put critical sections in our
own code before calling the cryptographic functions. We are
experiencing some crashes and attempting to track them down and
thought our use of OpenSSL may be faulty.

Regards,

Lide Wang

Re: DH Prime Question

[jimmy bahuleyan]

Bernhard Froehlich wrote:

Julian schrieb:

Hi,
I am working on an application that is both a client and a server. The 
DH prime is stored in the binary for the server. Since the Server will 
exists inside the Client is there a considerable risk of embedding the 
DH p into the code? The alternative is to have the Server generate a  
1024 bit prime when the Client starts it's Server portion, however as 
we know this is painfully slow.


Thanks,
J
As I understand it the prime inportance for DH parameters is that no 
attacker can trick you into using a special set of parameters. Insofar 
I'd see no problem embedding DH parameters in code, because if an 
attacker can modify your code than you'll have bigger problems than DH 
parameters.

Any other opinions?

Hope it helps,
Ted
;)



Agree with Bernhard.

Embedding doesn't seem to be a problem; many softwares use well known DH 
parameters (eg: ssh). What is important is for your DH params not to be 
weak, it might make be worth to look at places like RFC 4419 {Sections 
6,7}, RFC2409 {Section 6 gives the Oakley groups}.



-jb
--
Real computer scientists don't comment their code.  The identifiers are
so long they can't afford the disk space.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Possibly unintended side-effect in BIO_nread0

[Keller, Michael]

Hi, 

I wrote an SSL layer over a custom network layer (IOCP on Windows,
poll() on UNIX) for my employer, using the non-copy functions BIO_nread
and BIO_nwrite. I am aware that they are not "official", and in
particular lack documentation. So it doesn't make much sense to speak
about bugs, as there is no defined contract.

Nevertheless I think there may be an unintended side-effect in
BIO_nread0. The problem occurs when calling BIO_nread0 while there is no
byte pending in the BIO. Then, at cyclic buffer boundaries only (or so I
think), a byte gets "swallowed". I think the behavior stems from the
following code in bss_bio.c (version 0.9.8g, lines 299-305):

if (peer_b->len == 0)
{
char dummy;

/* avoid code duplication -- nothing available for
reading */
return bio_read(bio, &dummy, 1); /* returns 0 or -1 */
}

I didn't follow the implemenation completely, but in the same file, in
bio_read we get to (lines 216-218):

BIO_set_retry_read(bio); /* buffer is empty */
if (size <= peer_b->size)
peer_b->request = size;

... and then somehow this "requested byte" disappears, if we are at the
cyclic buffer wraparound - by "disappear" I mean that the next call to
BIO_nread0 will jump this byte. Note, that I am not sure about the
mechanics. All I can say is, that if I call BIO_nread0 on an empty BIO
then I get 1 byte lossage every 16KB.

When I wrap my code like this, everything works fine: 

if (BIO_ctrl_pending(pNetworkBio)) {
  ret = BIO_nread0(pNetworkBio,  (void *)&netwBuffer.buf);
}

So maybe the assumption is, that people do not call BIO_nread0 if there
is nothing pending in the BIO. But looking at the source, and especially
the comment (line 303 above) it seems to me the author just wanted to
avoid code duplication and *did not* intend any side-effect.

On a similar note I would like to ask if there are any plans to make
this interface official. I personally think it's an important interface
for any high-performance application.  

Please comment,
Michael Keller.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: DH Prime Question

[Julian]

My fear is that get a hold of P will allow for someone else to use it  
to start a protocol disassembly. For instance anyone could create a  
DHE-RSA-AES256-SHA TLS server and use P to listen for connections, of  
course if would have to have a cert signed by CA to proceed even if  
they have P.


The protocol here is TLS where each client is a server, so shouldn't  
each client/server have their own DH P?


Or am I looking at this wrong, since I am using distributed PKI, then  
exposing P is moot?


Thanks in advance.

J

On Apr 14, 2008, at 1:57 AM, jimmy bahuleyan wrote:

Bernhard Froehlich wrote:

Julian schrieb:

Hi,
I am working on an application that is both a client and a server.  
The DH prime is stored in the binary for the server. Since the  
Server will exists inside the Client is there a considerable risk  
of embedding the DH p into the code? The alternative is to have  
the Server generate a  1024 bit prime when the Client starts it's  
Server portion, however as we know this is painfully slow.


Thanks,
J
As I understand it the prime inportance for DH parameters is that  
no attacker can trick you into using a special set of parameters.  
Insofar I'd see no problem embedding DH parameters in code, because  
if an attacker can modify your code than you'll have bigger  
problems than DH parameters.

Any other opinions?
Hope it helps,
Ted
;)


Agree with Bernhard.

Embedding doesn't seem to be a problem; many softwares use well  
known DH parameters (eg: ssh). What is important is for your DH  
params not to be weak, it might make be worth to look at places like  
RFC 4419 {Sections 6,7}, RFC2409 {Section 6 gives the Oakley groups}.



-jb
--
Real computer scientists don't comment their code.  The identifiers  
are

so long they can't afford the disk space.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Using OpenSSL cryptographic functions in a multi-threaded application

[Mark]

>  We are using only the OpenSSL cryptographic 
> functionality, the EVP and 
> HMAC functions, in a multi-threaded application. Do we need to do 
> anything to ensure thread safety ? The documentation mentions 
> CRYPTO_set_locking_callback() and CRYPTO_set_id_callback() 
> ,but we are 
> not calling these functions nor have we put critical sections in our 
> own code before calling the cryptographic functions. We are 
> experiencing some crashes and attempting to track them down and 
> thought our use of OpenSSL may be faulty. 

You must always using the locking functions in a multithreaded
application.

Mark.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: DH Prime Question

[jimmy bahuleyan]

Julian wrote:
My fear is that get a hold of P will allow for someone else to use it to 
start a protocol disassembly. For instance anyone could create a 
DHE-RSA-AES256-SHA TLS server and use P to listen for connections, of 
course if would have to have a cert signed by CA to proceed even if they 
have P.


Without certificates (anon-DH), yes someone could do a man-in-the-middle 
attack; with certificates they would be hard pressed, since they 
wouldn't have the server's private key. As for listening, no matter what 
P you use a listener could easily follow the protocol; but TLS is 
designed to be resilient, so he couldn't get hold of the session keys.





The protocol here is TLS where each client is a server, so shouldn't 
each client/server have their own DH P?


Or am I looking at this wrong, since I am using distributed PKI, then 
exposing P is moot?




P,G are DH parameters which both the server and client need to know. 
Normally they are public knowledge; if the server and client don't share 
the P,G, then the server sends it to client (DH can't work if both don't 
have the same P,G).


So, what happens is

client makes a random value Y which is private.
server makes a random value X which is private.

client uses {P,G} to make public value Y' from Y.
server uses {P,G} to make public value X' from X.

exchanges X',Y' and both arrive at a common value Z.

The security of DH lies in the fact that any attacker given knowledge of 
X',Y',G,P cannot derive X or Y (Discrete Logarithm problem) and hence 
cannot derive Z. And normally all systems generate X,Y for each DH exchange.


Hope that helps.


-jb
--
Real computer scientists don't comment their code.  The identifiers are
so long they can't afford the disk space.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: DH Prime Question

[Julian]

Thanks jb that clears up a lot.

j

On Apr 14, 2008, at 6:14 AM, jimmy bahuleyan wrote:


Julian wrote:
My fear is that get a hold of P will allow for someone else to use  
it to start a protocol disassembly. For instance anyone could  
create a DHE-RSA-AES256-SHA TLS server and use P to listen for  
connections, of course if would have to have a cert signed by CA to  
proceed even if they have P.


Without certificates (anon-DH), yes someone could do a man-in-the- 
middle attack; with certificates they would be hard pressed, since  
they wouldn't have the server's private key. As for listening, no  
matter what P you use a listener could easily follow the protocol;  
but TLS is designed to be resilient, so he couldn't get hold of the  
session keys.



The protocol here is TLS where each client is a server, so  
shouldn't each client/server have their own DH P?
Or am I looking at this wrong, since I am using distributed PKI,  
then exposing P is moot?


P,G are DH parameters which both the server and client need to know.  
Normally they are public knowledge; if the server and client don't  
share the P,G, then the server sends it to client (DH can't work if  
both don't have the same P,G).


So, what happens is

client makes a random value Y which is private.
server makes a random value X which is private.

client uses {P,G} to make public value Y' from Y.
server uses {P,G} to make public value X' from X.

exchanges X',Y' and both arrive at a common value Z.

The security of DH lies in the fact that any attacker given  
knowledge of X',Y',G,P cannot derive X or Y (Discrete Logarithm  
problem) and hence cannot derive Z. And normally all systems  
generate X,Y for each DH exchange.


Hope that helps.


-jb
--
Real computer scientists don't comment their code.  The identifiers  
are

so long they can't afford the disk space.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

SSL overhead

[Tomas Neme]

We have our own TCP implementation, and we're thinking of using a
BIO_s_mem to add an SSL layer to it. The plan is: read the socket, put
the encrypted data into the ssl object's BIO, and then do a read from
it. Likewise, produce the data, feed it into OpenSSL, and then take
the data from the BIO and put it into the socket.

We want to minimize memory allocation, working with a fixed-size
buffer, so I'd like to know if there's a way to know the size overhead
on SSL headers, so I know that if I feed it, say 200B blocks, I have
to read with a 350B buffer, or something like that.

Is there some way to know that?

thanks
Tomas

-- 
|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

problem with PKCS7_decrypt

[shankar ks]

Hi ,

I have encrypted the data using pkcs7_encrypt and stored the content in one
file . and I called the same file as a input for the decrypt using
pkcs7_decrypt Api and copied the data to a file .
then if i open the output file, i have the orginal data which i encrypted .
but the problem is on each line end of the file has one extra charecter . (
the charecter is  "c " and under c "r ").

can any body has any idea on this..


-- 
--Best Regards
Shankar

Re: problem with PKCS7_decrypt

[Dr. Stephen Henson]

On Mon, Apr 14, 2008, shankar ks wrote:

> Hi ,
> 
> I have encrypted the data using pkcs7_encrypt and stored the content in one
> file . and I called the same file as a input for the decrypt using
> pkcs7_decrypt Api and copied the data to a file .
> then if i open the output file, i have the orginal data which i encrypted .
> but the problem is on each line end of the file has one extra charecter . (
> the charecter is  "c " and under c "r ").
> 

Sounds like the canonical translation mentioned in the manual pages. Try
including the flag PKCS7_BINARY to PKCS7_{encrypt,decrypt}.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: DH Prime Question

[Michael Sierchio]

Julian wrote:
My fear is that get a hold of P will allow for someone else to use it to 
start a protocol disassembly. For instance anyone could create a 
DHE-RSA-AES256-SHA TLS server and use P to listen for connections, of 
course if would have to have a cert signed by CA to proceed even if they 
have P.


The protocol here is TLS where each client is a server, so shouldn't 
each client/server have their own DH P?


No.  All participants share a prime generator and a modulus. A DH
secret key is therefore essentially merely a random string of bits
of a certain length.  The corresponding public key is p^privkey mod m.

Trust requires you have some mechanism to know that a given set of
bits is the pubkey belonging to the other party.

The benefit of DH is that once you and your correspondent have each
other's public keys, you can begin encrypted communication without
a handshake.  There is an implicit pairwise shared secret which you
can use to generate session keys via some established mechanism (see
SKIP as an example).

- M



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL overhead

[Tomas Neme]

I'm getting started with ssl, and there's a lot of things I don't get
about the library, small, and quite a lot of them

Isn't there an IRC channel, or some kind of faster communication way than this?

The documentation's poor at best, and I don't completely get the
general concepts. From reading examples I figure that only the
BIO_f_ssl does encryption-decryption when written into? so what should
I do if I want to provide an api that has functions b_encrypt and
encrypt_flush? I have to use OpenSSL with memory buffers, because I
can't give it direct access to sockets, so I'm wondering how to handle
the handshakes and whatnot in a non-blocking way. Do I need 2
BIO_f_ssls, one for imput and one for output, or what? I just want an
object which will take data, encrypt it and put it in a buffer, which
I can use to write into the socket, and that will read encrypted data
that I will take from a socket, and put the decrypted version into a
buffer, so I can pass it to my http client. I don't want the SSL
object to handle the sockets directly because this has to be portable,
but I don't fully understand which kinds of BIOs do I need to model
this data flow, and how do I handle the handshakes and the such.

Tomas

---
|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL overhead

[Tomas Neme]

>  general concepts. From reading examples I figure that only the
>  BIO_f_ssl does encryption-decryption when written into? so what should

Or doing SSL_write into a SSL object with a BIO_s_mem object as the
write-bio will write the encrypted data into it?

T

-- 
|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: usig apache and pkcs12 for auth, pass phrase needed

[Deceased]

One dev wrote:

El vie, 11-04-2008 a las 17:01 +0300, Deceased escribió:

Hi,

I'm using apache and pkcs12 certs to for auth., but I cannot make web 
browser to ask pass phrase every time I connect to it, only for import 
pass on cert install. I'm using firefox.
Is there any way to make pkcs12 certs that require pass phrase for auth, 
or any other cert file that works with firefox.

Server asking for certificate:
Client cert only need "open" crypto store of browser with pass phrase.
If you want that server ask for client certificate you need set this
flag in server configuration, host or virtual host, ssl.conf

Browser asking a pass phrase:
If you want that firefox ask for key of crypto store, you can close the
browser. You can adjust firefox configuration to enable the request of
pass phrase to access store of certificates.


Thank You in advance.

here's how whole thing was done :

*Create the Certificate Authority (CA)*

openssl genrsa -out ca.key 1024
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

*Have the Client Request a Certificate*

openssl genrsa -out client.key 1024
openssl req -new -key client.key -out client.csr -config openssl.cnf

*Have the Authority Sign the Certificate*

openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in 
client.csr -out client.crt


*Import the Client Certificate*

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out 
client.p12

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Ok, thanks for reply, although thats not what i need.
I'll have to find another way.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL overhead

[Goetz Babin-Ebell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomas Neme wrote:

| The documentation's poor at best, and I don't completely get the
| general concepts. From reading examples I figure that only the
| BIO_f_ssl does encryption-decryption when written into? so what should
| I do if I want to provide an api that has functions b_encrypt and
| encrypt_flush?

If you want to do SSL, you should stick with BIO_f_ssl.
If you want to do some other encryption, you can use BIO_f_cipher.

| I have to use OpenSSL with memory buffers, because I
| can't give it direct access to sockets, so I'm wondering how to handle
| the handshakes and whatnot in a non-blocking way.

How good is your C ?
you could look into bio_s_socket and implement your own bio.
After you understood the concept behind BIO, it is simple to do...

| Do I need 2
| BIO_f_ssls, one for imput and one for output, or what?

No. you treat it almost as a normal socket:
You write data to be encrypted (and sent to the peer) into it and
read decrypted data (received from the peer) from it.

| I don't want the SSL
| object to handle the sockets directly because this has to be portable,
| but I don't fully understand which kinds of BIOs do I need to model
| this data flow, and how do I handle the handshakes and the such.

The SSL bio is just a filter.
It relies on an underlying BIO to do the low level IO communication.
This way you can use different network implementations to transport
the encrypted data.


Goetz

- --
DMCA: The greed of the few outweighs the freedom of the many
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIA8EP2iGqZUF3qPYRAr0EAJ0fVnuLUsKWjJiaNdjxuQrTx5XeAwCfa+jG
dDf6VRyXthXB+QJ4ye6i/cQ=
=Adx8
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: SSL overhead

[David Schwartz]

> The documentation's poor at best, and I don't completely get the
> general concepts. From reading examples I figure that only the
> BIO_f_ssl does encryption-decryption when written into? so what should
> I do if I want to provide an api that has functions b_encrypt and
> encrypt_flush?

I think you have a wrong notion in your head that's leading you astray. You
are thinking about an SSL connection as a module that you put some plaintext
into, some encrypted data comes out, and then you send that on a socket, you
get some encrypted data back, you feed that into the SSL connection, and you
get some plaintext back.

While that certainly *sometimes* happens, other times it doesn't happen.
Sometimes you want to hand plaintext to the SSL engine, but it can't encrypt
it yet because it hasn't negotiate the key. Sometimes data comes in from the
socket that's protocol data and doesn't correspond to application data.

Your whole concept of "how big does my buffer have to be" is based on the
mistaken notion that it's useful to try to track what goes in to its
corresponding output. It's not. That's the SSL engine's job.

It is better to think the the SSL engine as a box that has four 'links'. One
is the one you feed plaintext into so that it can be encrypted and sent. One
is the one encrypted data comes out of. One is the one that you get
decrypted plaintext from. One is the one that data that comes in from the
wire is fed into. The relationship between these four links to 100% the SSL
engine's business, and you shouldn't make any assumptions about it.

If you hand plaintext to the SSL engine, at some point it might hand
encrypted data to you to send over the Link. Or it might not. That's not
your business. If you get encrypted data from the other end, give it to the
SSL engine. It might output some plaintext for you to treat as received, or
it might not. That's not your business.

You have two general approaches to choose from. You can implement a BIO and
OpenSSL will call into your BIO whenever it needs to send or receive data to
or from the other end. This will result in your calls to SSL_read/SSL_write
making calls into your own send/receive functions when the SSL engine needs
to interact with the link to the other end. This is probably the simpler
approach and it makes deadlocks easier to avoid.

The other way is to use BIO pairs. With A BIO pair, you actually
independently manage all four links independently. When you get data from
the other end of the SSL link, you will actually 'write' it onto the
appropriate link. When you make forward progress, you will actually call a
'read' function to get data from OpenSSL that you send to the other end.
This is a bit trickier to do as it is easy to inadvertently cause deadlock,
especially in non-blocking implementations.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

How to use a custom elliptic curve in crypto/ec?

[Mark Hansen]

Does anyone know of any documentation or examples on how to use a custom 
elliptic curve with ECDSA and ECDH of openssl's crypto library?


It doesn't look like support of custom curves is built-in.  So, I have 
tried to duplicate what was done with built-in curves in 
"crypto/ec/ec_curve.c" to setup a custom curve in my own code, but it is 
not working.


Thanks,
-Mark Hansen
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Hash input and output

[Dave Thompson]

> From: [EMAIL PROTECTED] On Behalf Of Badra
> Sent: Friday, 11 April, 2008 09:57

> static char *login="login";
> static char *password="password";
> static char *label="label";
>
These could better be pointers to const char, since you shouldn't
and don't try to modify the strings pointed to.

> const unsigned char *buf=NULL;
> strcat(&buf, login); strcat(&buf, password); strcat(&buf, label);
>
If you've posted your actual code (not mistyped it), this is totally wrong.
You are overwriting the POINTER buf (assuming NULL is all-zero as is usual
though not absolutely required) and whatever happens to follow it in memory.
If you are using a C implementation (compiler) that conforms to the
standard,
and in a conforming mode (which often is not the default), it is required
to diagnose the type mismatch here (u-char** expecting char*).

Any C textbook should cover this in the first chapter or two.
Either declare buf as a large enough (non-const!) array of u-char,
or as a pointer AND SET IT to point to enough malloc'ed space.
Pass the array 'value' or pointer to access the allocated space.
And if that space is not initialized, strcpy() the first piece
since strcat() won't (reliably) start at the beginning;
alternatively set (at least) byte [0] to zero then strcat().

Note that 'char*' (pointer to 'plain' char) and 'unsigned char*'
(to unsigned char) are formally incompatible types in standard C,
so you should cast to char* for strcpy/strcat. If you are dealing
with data that is actually plain chars, as here, it's probably easier
to make buf array of or pointer to plain char, and only cast it
to unsigned char * when passed (once) to SHA1().

Also, simply concatenating texts is generally bad practice,
as depending on your usage it may allow length-tampering attacks.
You usually want to have some separator that can't occur in the data
either because of semantic requirements (e.g. colon or tilde)
or representation (e.g. null byte for C strings); or prefix lengths.

> unsigned char *m1[20];
> unsigned char *m2[20];
>
> SHA1(&buf, strlen(&buf), m1); // The output is:
> 3d79ad220830e96dabd6ae6f9973306df1800906
>
m1 is the wrong type here (array of POINTER TO u-char, when it should be
just array of u-char) and again your compiler should warn. However,
20 pointers will everywhere be at least as big as 20 u-chars, and almost
everywhere substantially larger, so this is not immediately harmful.

> //the output of the above SHA1 will be used as an input for the SHA1
> below, after concatenating it with label
>
> strcat(&m1, label);
> SHA1(&m1, str len(&m1), m2);
>
In addition to Marek's point that the output of (the first) SHA1 may
contain null byte(s) and thus get truncated, in the case that it doesn't
(probability about 92%) if the memory following the first 20 bytes of m1
contains garbage, as is likely if it is 'auto' since it isn't initialized,
that probably irreproducable garbage is included into your concatenation.
And it may run off the total space (probably 20 * 4bytes on most systems
today)
and clobber something else -- perhaps but not necessarily m2.

Instead you should declare m1 as array of u-char (or char) long enough
to contain the first hash (20) plus whatever you want to add (here 5+1),
or alternatively as pointer to u-char (or char) and malloc() enough space,
then direct the first SHA1() into the first 20 bytes and:
  strcpy (m1+20, label);



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Security pedanticism versus usability (and where PKIX fails)

[Dave Thompson]

> From: [EMAIL PROTECTED] On Behalf Of Kyle Hamilton
> Sent: Thursday, 10 April, 2008 07:39

> David Schwartz wrote:
> >  And with respect to the other thread, I agree with you. The 
> level of security should be the highest that doesn't require 
> sacrificing things that are more important than security. 
> Sometimes all you need is to keep out your kid sister, 
> 
> X.509 was written to support SET (Secure Electronic Transactions), and
> standardize the things that SET needed.  X.509 wasn't appropriate to
> the Internet, and that's why the "Internet Profile" (PKIX) was issued.
> 
Huh? SET used X.509, as did PEM PKCS/SMIME and SSL et seq, but it was 
written for X.500 and X.400 and potentially other ISORMs back in the 1980s.

SET actually "needed" (at least chose) to add a (small) extension -- 
using the generic framework for extensions that X.509v3 did standardize, 
and that many others have also used.

Even if you mean that SET was (reasonably) well suited to X.509's intended 
trust model, that occurred indirectly, because they both independently 
tried to model real-world business relationships, and unsurprisingly 
came up with similar results ...

> Unfortunately, the people who wrote the PKIX were people trying to
> make the protocol have the things that the financial
> services/fiduciary communities needed.  Many of the things in there
> just do not apply to the things that general users of the Internet use
> the Internet for.
> 
... which (business trust model) as you point out isn't the same as 
sometimes desireable for cyberspace activities.




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]