Re: does ASN1_UTCTIME_get() changes by local time zone settings
Joe Gluck wrote: 1. I don't expect any thing developed specilay for me, I was just wondering if there is any one out there that knew about a function that already exists and does it. 2. I am not designing a system to break in 10 years, I am thinking of better performance for the time until we need to find a better solution. Have you measured that performance and found the simple string comparison (coupled with optional parsing) to be the main contention point in your application? Have you used profiler to confirm your performance suspicions? If not, please do. You'll be thoroughly surprized. BTW why will I run into trouble at 2015 it should be good up to 2037? Am I missing some thing? In 2015 there will be certificates which will break in 2037, like now there are these which break in 2015. Thanks, Joe On 1/31/06, David Schwartz [EMAIL PROTECTED] wrote: I will not get certificates today for after 2045 because the certificates that I am checking are certificates that already past a validation check and have been inserted into my cache system, therefor it is a certificate signed by our own system which does not sign for more then 25 year. most are 1 year. Thanks Joe You may have a special case, but you can't expect the library to be designed for your special case. You'll run into trouble after 2015 anyway -- any special reason you're designing things to break in 10 years? DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: does ASN1_UTCTIME_get() changes by local time zone settings
Joe Gluck wrote: I did not bother to check the performance, just because it is obvious that it is more time, You might be surprized to discover that the obvious thing is not true. http://www.faqs.org/docs/artu/optimizationchapter.html http://www.cookcomputing.com/blog/archives/84.html http://www.flounder.com/optimization.htm http://www.petefreitag.com/item/509.cfm and even if it is not a lot, why not be better while I know that performance is a major issue on our system. I am willing to bet $20 bucks that if you do it with string parsing and comparison, it won't even be in the top 10 issues affecting the performance of your application in its steady normal operation. Please consider trying it out. Any way, thank you every one, who participated on this thread. Thank you for raising this issue. On 1/31/06, Lev Walkin [EMAIL PROTECTED] wrote: Joe Gluck wrote: 1. I don't expect any thing developed specilay for me, I was just wondering if there is any one out there that knew about a function that already exists and does it. 2. I am not designing a system to break in 10 years, I am thinking of better performance for the time until we need to find a better solution. Have you measured that performance and found the simple string comparison (coupled with optional parsing) to be the main contention point in your application? Have you used profiler to confirm your performance suspicions? If not, please do. You'll be thoroughly surprized. BTW why will I run into trouble at 2015 it should be good up to 2037? Am I missing some thing? In 2015 there will be certificates which will break in 2037, like now there are these which break in 2015. Thanks, Joe On 1/31/06, David Schwartz [EMAIL PROTECTED] wrote: I will not get certificates today for after 2045 because the certificates that I am checking are certificates that already past a validation check and have been inserted into my cache system, therefor it is a certificate signed by our own system which does not sign for more then 25 year. most are 1 year. Thanks Joe You may have a special case, but you can't expect the library to be designed for your special case. You'll run into trouble after 2015 anyway -- any special reason you're designing things to break in 10 years? DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ASN1_INTEGER == int
Peter Sylvester wrote: The reverse may not be true in real life. One way this comparison might bite you is when the issue issues certificate with encoding violating the DER requirements. For example, the ASN1_INTEGERs with octet encodings 02 and 00 02 contain the same value 2, but these encodings will in fact be different if you compare them with memcmp. The latter (00 02) is incorrect encoding, violating DER. It violates even BER as far as I remember Since X.409 1984 the text says: The value of the integer shall be encoded in the fewest possible octets the first (most significant) 9 bits shall not all be ones or zeros. X.409 is obsolete. However, X.690 is indeed says so, you are correct. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ASN1_INTEGER == int
David Schwartz wrote: Clarification: In DER, the following is prohibited: 1. leading zero bytes if the next non-zero octet does not start with bit 7 set (0x80 mask). 2. leading 0xff (-1, 255) bytes, if the next non-0xff octet starts with bit 7 set (0x80 mask). Thanks for the clarification. It tooks me about as many times to get it right in my BER/DER code as it does for me to get it right in communication. ;) The DER specification requires an integer to be encoded into octets using 2's complement and as few octets as possible. This means you cannot have a leading zero unless the high bit of the next octet is set. Similarly, you cannot have a leading 0xff unless the high bit of the next octet is clear. The most-significant bit is always the sign bit. So (all numbers in hex): 00 20 : Illegal DER, leading 00 not needed 00 80 : Legal, leading 00 needed to make number positive FF 03 : Legal, leading FF needed to make number negative FF D0 : Illegal DER, FF not needed Note that these are all legal BER and are all perfectly valid and meaningful integer encodings. DER, however, requires the minimum number of octets to be used. As rightfully pointed out by Peter Sylvester, in this respect BER is equivalent to DER as well. In cryptography applications, DER is important because if you change the binary representation of a certificate or public key, its checksum will change and signatures would be invalidated. DER allows you to convert a key or certificate to a native format, then write it back out and get the exact same representation. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ASN1_INTEGER == int
Joe Gluck wrote: Hi, I would like to know if there is a Isomorphism between a serial number represented as a ASN1 and if I had that number in int? If it is true than i can just use most of the times the original ASN1 as a unique id, instead of parsing it into a int value. (If I know they are from the same issuer and that he does not give out two certs with the same serial number) The ASN.1 INTEGER type may include integers which are wider or narrower than the native int type (for example, has 296 bits wide). Thus, one cannot substitute ASN1_INTEGER by int. On the other hand, in the X.509 realm comparing ASN1_INTEGER is safe, as the integer (by DER standard) it encoded in minimum number of octets. Thus, if two ASN1_INTEGERs contains the same bytes (lengths are equal and memcmp() over contents gives 0) they contain the same integer value. The reverse may not be true in real life. One way this comparison might bite you is when the issue issues certificate with encoding violating the DER requirements. For example, the ASN1_INTEGERs with octet encodings 02 and 00 02 contain the same value 2, but these encodings will in fact be different if you compare them with memcmp. The latter (00 02) is incorrect encoding, violating DER. You might as well disregard such certificate as non-compliant. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ASN1_INTEGER == int
Kyle Hamilton wrote: Alright, there's a SEVERE disconnect here versus the description of an integer as described in the thread openssl can don' t handle 20 Octes long Serial Numbers RFC 3280. If you substitute 296 with 80, the SEVERE disconnect will go away, right? If so, please consider this substitution to be effective immediately. Even so, every other statement in my original reply holds. This needs to be rectified soonest. On 1/27/06, Lev Walkin [EMAIL PROTECTED] wrote: The ASN.1 INTEGER type may include integers which are wider or narrower than the native int type (for example, has 296 bits wide). Thus, one cannot substitute ASN1_INTEGER by int. On the other hand, in the X.509 realm comparing ASN1_INTEGER is safe, as the integer (by DER standard) it encoded in minimum number of octets. Thus, if two ASN1_INTEGERs contains the same bytes (lengths are equal and memcmp() over contents gives 0) they contain the same integer value. The reverse may not be true in real life. One way this comparison might bite you is when the issue issues certificate with encoding violating the DER requirements. For example, the ASN1_INTEGERs with octet encodings 02 and 00 02 contain the same value 2, but these encodings will in fact be different if you compare them with memcmp. The latter (00 02) is incorrect encoding, violating DER. You might as well disregard such certificate as non-compliant. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ASN1_INTEGER == int
David Schwartz wrote: Alright, there's a SEVERE disconnect here versus the description of an integer as described in the thread openssl can don' t handle 20 Octes long Serial Numbers RFC 3280. If you think there's a disconnect, you are confused. This needs to be rectified soonest. There is no disconnect. For a negative number, prefixing it with a zero-byte changes the meaning, because the most significant bit is the sign bit. For a positive number, adding a zero-byte to the beginning does not change the value. However, the DER specification requires you to encode an integer in as few bytes as possible. Of course, it is impossible to remove the leading zero byte from a negative number if the high bit of the next byte is not zero, as that would change the value. Addition: You could remove the leading 0xff byte from such number, if the next octet has bit 7 (0x80) set. However, it is possible to remove the leading zero byte from a positive number, so such leading zero bytes are prohibited by the DER specification. Clarification: In DER, the following is prohibited: 1. leading zero bytes if the next non-zero octet does not start with bit 7 set (0x80 mask). 2. leading 0xff (-1, 255) bytes, if the next non-0xff octet starts with bit 7 set (0x80 mask). The BER specification defines what the encodings mean. The DER specification specifies a unique way to encode any given value. Analogously, we all know what number 03 is, but if we were picking a unique way to encode the number three, it would be 3 not 03. What exactly do you think is the disconnect? DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Joe Gluck wrote: That attack is interesting, how can that be done, (sorry for bothering you :-) ) But cutting down the X509_cmp will not work because the memcmp compares the hash which if I will cut out the X509_check_purpose lines will not make any sense. But I think the best idea is to compare the entire text of the entire certificate (The text as I get in a PEM format before loading it into the X509 object. it is faster than hashing the same size and comparing the hash. You should then consider comparing DER encoding, not the PEM wrapper around the DER certificate contents. PEM encoding of the same certificate can be different, due to relaxed rules about whitespace characters. Thanks On 1/26/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Thu, Jan 26, 2006, Joe Gluck wrote: Thank you. I still am not sure if it the best idea, Because i will be getting for example 1,000,000 a times in a day the same certificate, I don't want to do that even short process if not necessary, what I could do is compare the times between X509_cmp() and my code, or even to doing memcmp() on the original text of the X509. So I would like to know if any one thinks there is a problem with how i am doing it, or if it will be slower then using some other way to do it? Your algorithm ends up accessing X509 structure internals which isn't a good idea if it can be avoided. It also doesn't compare the whole public key: you'd also need to compare the algorithm type and its parameters (if any). There are sound reasons as to why you should also check parameters. If you don't there are some interesting key substitution attacks that could spoil your whole day... If structure internal access is considered acceptable you can cut the whole thing down to the memcmp() of X509_cmp(). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Joe Gluck wrote: That is correct but in my case I am getting the cert in PEM, and it is created by another application we develop so it should be an exact duplicate if it is actually the same one. This is only true if you can guarantee that the certificate in PEM reaches your system only once. If you can transfer PEM from the application your team is developing using different means (email, file transfer, web publishing), it is practically guaranteed that the PEM contents would not match. If only for different line ending conventions between different systems. Even if you can guarantee that the certificate reaches your certificate storage only once, you can just as well compare a pointer to the structure which keeps this certificate's PEM contens. On 1/26/06, Lev Walkin [EMAIL PROTECTED] wrote: Joe Gluck wrote: That attack is interesting, how can that be done, (sorry for bothering you :-) ) But cutting down the X509_cmp will not work because the memcmp compares the hash which if I will cut out the X509_check_purpose lines will not make any sense. But I think the best idea is to compare the entire text of the entire certificate (The text as I get in a PEM format before loading it into the X509 object. it is faster than hashing the same size and comparing the hash. You should then consider comparing DER encoding, not the PEM wrapper around the DER certificate contents. PEM encoding of the same certificate can be different, due to relaxed rules about whitespace characters. Thanks On 1/26/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Thu, Jan 26, 2006, Joe Gluck wrote: Thank you. I still am not sure if it the best idea, Because i will be getting for example 1,000,000 a times in a day the same certificate, I don't want to do that even short process if not necessary, what I could do is compare the times between X509_cmp() and my code, or even to doing memcmp() on the original text of the X509. So I would like to know if any one thinks there is a problem with how i am doing it, or if it will be slower then using some other way to do it? Your algorithm ends up accessing X509 structure internals which isn't a good idea if it can be avoided. It also doesn't compare the whole public key: you'd also need to compare the algorithm type and its parameters (if any). There are sound reasons as to why you should also check parameters. If you don't there are some interesting key substitution attacks that could spoil your whole day... If structure internal access is considered acceptable you can cut the whole thing down to the memcmp() of X509_cmp(). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Attribute order in name comparison
Robert Eiglmaier wrote: Hi, I have troubles verifying a PKCS#7 signedMessage because the order of the DN attributes in the signerInfo is different from the order in the certificate. i. e. The cert contains: C=DE/O=Org/CN=Alice The signer info has: CN=Alice/O=Org/C=DE I found that the function int X509_NAME_cmp(const X509_NAME *a, const X509_NAME *b) will only find the names matching if the attribute order is identical. It wouldn't be a big deal to make X509_NAME_cmp() more tolerant, but since appearantly nobody has had such a problem yet I'd like to know if there is a specification somewhere that says something like Thou shalt not turn around the order of thy name attributes. PKIX1 profile for X.509 certificates, as well as X.680 for ASN.1 SEQUENCE. All I found was a statement, that SEQUENCE OF is ordered. (distinguishedName is a SEQUENCE OF nameAttribute) But when I look at an example Certificate I can't see by what it is being ordered here: SEQUENCE ^^ this is a SEQUENCE OF, not SEQUENCE SET SEQUENCE OBJECT:countryName 2.5.4.6 PRINTABLESTRING :DE SET SEQUENCE OBJECT:organizationName 2.5.4.10 PRINTABLESTRING :Company SET SEQUENCE OBJECT:commonName 2.5.4.3 PRINTABLESTRING :Demo CA Can anyone bring some light into the darkness? They are ordered sequence of unordered SET's of each element. The order inside SET OF is not important, but there is exactly one element in each SET OF. However, the order inside SEQUENCE OF is important. And the order is the order of display, i.e. DE/Company/Demo CA. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ideas on replacing where ERR_STATE is stored?
Michael Sierchio wrote: Steven Reddie wrote: Hi Michael, I'm familiar with that approach, having used it many times myself. The choice of poll over select isn't important since they're basically the same; in fact, poll is sometimes implemented with select. Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. I think you're confusing a file I/O notification with mutual exclusion and condition variables paradigm, another kind of IPC. The following page provides necessary background information: http://www.kegel.com/c10k.html Besides, some select() implementations are actually poll()-based. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ideas on replacing where ERR_STATE is stored?
Michael Sierchio wrote: Jack Lloyd wrote: I believe Michael is actually talking about the thundering herd problem, when many processes are all waiting on a single event, which only one of them will end up responding to. That is a classic problem affecting some uses of select (and also accept, and IIRC a few other socket calls as well). Precisely what I was thinking, though I suppose I should have actually said it. ;-) Thanks. Yes, but your words Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. are not substantiated. Poll() provides no advantage over select() for the thundering herd problem. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ideas on replacing where ERR_STATE is stored?
Jack Lloyd wrote: On Mon, Oct 17, 2005 at 02:43:19PM -0700, Lev Walkin wrote: Michael Sierchio wrote: [skip] Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. I think you're confusing a file I/O notification with mutual exclusion and condition variables paradigm, another kind of IPC. The following page provides necessary background information: I believe Michael is actually talking about the thundering herd problem, when many processes are all waiting on a single event, which only one of them will end up responding to. That is a classic problem affecting some uses of select (and also accept, and IIRC a few other socket calls as well). Including poll(). -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1124] Standart ISO 8601 violation(Bug in ASN1_GENERALIZEDTIME_set?)
Richard Levitte via RT wrote: [levitte - Wed Jun 22 16:31:26 2005]: GeneralizeTime is defined in X.680 and ISO/IEC Internal Standard 8824- 1. Read carefully, it specifies that the date part should be formatted as specified in ISO 8601, as well as the time part, but it doesn't say that the combined value should be constructed as described in ISO 8601. All it says is that the time part should be appended to the date part, and that the combination should optionally get Z or a time zone specification appended to it. No T anywhere. Of course, you could then say that the definition of GeneralizedTime is in violation with ISO 8601. That's something to bring up with ISO/ITU- T. It does not, actually. === quote ISO8601-2000, clause 5.4.1 === NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a combined date and time of the day representation with others defined in this International Standard. === -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: resources rather than values in openSSL functions
to program's crash. Consequently, all statements about security (or insecurity) of any decisions related to pass-by-value or pass-by-reference should be written extremely carefully, certainly not like this was so because of security reasons, and better be dropped altogether. So, I would rewrite the following phrase Our inference is that the authors of the module wished to limit the number of copies of these values in memory, both for performance and security reasons. into something like that: Our inference is that the openssl module it is a simple hack to allow PHP programmers to use the OpenSSL library written at a lower level language not easily supporting some of the features to which PHP users have become accustomed. Or something like that. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[Fwd: Re: Certificate date validation]
Bommareddy, Satish (Satish) wrote: How do I check to see how many days are left for the validity of a certificate. Is there a openssl command which tells me the days or time left? X509_cmd_current_time returns a positive integer if a certificate is till valid? No. What does this signify? It's cmp (compare), not cmd. It just returns -1, 0 or 1 when the given time is less than, equal to, or greater than the current wall clock time value. Consequently, you can't just use its return value directly, as you'll have to compare TWO time values from the certificate with the current wall clock. 1. Get the current wall clock time (time(3)) 2. Fetch the notBefore and notAfter time values from the certificate. These time values indicate the time range when the certificate is valid. (Use X509_get_notBefore and X509_get_notAfter for fetching). 3. Compare the notBefore time with the wall clock time using X509_cmp_time (which takes the time_t argument instead of re-evaluating the wall clock time each time, as X509_cmp_current_time does). If result is positive, then the notBefore time is greater than the current time, hence the certificate is not _yet_ valid. Abort. 4. Compare the notAfter time with the wall clock time using X509_cmp_time. If result is negative, then the notAfter time is earlier than the current clock time, hence the certificate is not valid anymore; abort. Is there a way to convert this to the time left? No. What I am trying to do is write a app to check the certificate and give me the days left. For this task, you'll have to 1. Extract the notAfter time value from the certificate (X509_get_notAfter). 2. Convert that time into the number of seconds from epoch (the same thing time(3) or gettimeofday(2) returns). That is quite easy in case of valid DER encoded certificates, which may not always be this way. 3. Substract the time(3) value from the value from step 2. 4. Divide by 86400. 5. Voila, that would be the (possible negative) number of days left. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: moving server key/cert from os x to win32
P. George wrote: is it okay/do-able to take a working cert/key pair created on an os x machine and copy it to a winxp box? Yes. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: moving server key/cert from os x to win32
P. George wrote: is it okay/do-able to take a working cert/key pair created on an os x machine and copy it to a winxp box? Yes. okay. do i need to alter it in _any_ way? No. The certificates are ASN.1 DER-encoded structures which are cross-platform by definition. These DER encoded chunks are later wrapped in base64 to facilitate transfers through strictly 7-bit systems or to ease doing cut-n-paste. These wrappings are known as PEM, and you probably have a certificate/key in this format. I believe the single problem with PEM which could occur, is unexpected line endings (\n vs \r\n, etc), but this is highly unlikely, as base64 decoders are supposed to ignore the whitespace characters. If you have a problem with line endings, just convert PEM to DER and copy the file to your target platform, but again, it is highly unlikely you'll ever need it. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: porting openssl code from *nix to win32...
P. George wrote: i am trying to get the following little hello-world ssl sample to run on win32 using winsock2: http://www.uweb.ucsb.edu/~jramrus/stuff/NetProgs/ssl_server.c it compiles and runs fine on my os x machine. however, when i take the same code and drag it over to windows and add a call to WSAStartup() before the call to socket() and add all the libraries and includes that are applicable to windows and remove the includes that are only for *nix, it fails when it gets to SSL_read(). it blocks on accept() as it is supposed to, and when i connect (but do _not_ yet send any data) i see the connection on the server, but then it dies on SSL_read(), which is weird, because i haven't sent any actual data over yet (at that point). if i call SSL_get_error() on the next line, i get: SSL_ERROR_SYSCALL . the documentation is kinda vague about what that actually means and what to do about it. what am i doing wrong here? Please show us a stack trace. How did it die? -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bind: Address already in use
P. George wrote: i found a nice little demo ssl server that works at: http://www.uweb.ucsb.edu/~jramrus/stuff/NetProgs/ssl_server.c please glance at this very short source file and tell me why when i hit control+c to stop it, that it won't let me launch it again without first rebooting the computer. after control+c, relaunch attempts yield the error: bind: Address already in use if i connect properly and send it a string to print, it prints the string perfectly and exits. subsequent launches work fine. it's just after force-quitting with control+c that it won't let me launch again. This is a basic question on socket programming. It is not related to OpenSSL development. In short, you have to call setsockopt(..., SO_REUSEADDR, ...) before calling bind(3) in that program. That'll solve it. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Finally time for IPvn support
Richard Levitte - VMS Whacker wrote:
Hi,
I've just been hacking around a little bit to add IPv6 capability, and
I thought of syntax for host and port specifications.
As it is now, the syntax used a little everywhere in OpenSSL is
{host}:{port}. Unfortunately, if we're to support IPv6 numeric
addresses, I find myself in a little bit of trouble, as IPv6 numeric
addresses contain colons! That makes it hard to distinguish the port
delimiter with parts of the IP address...
So, I'm looking for proposals on a new syntax to separate IP address
from port number. Any suggestion?
This is how Cisco does that:
http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_ip_version_60900aecd800c111e.html
This is another informal proposal:
http://lists.debian.org/debian-ipv6/2000/01/msg00030.html
Also see:
http://gbiv.com/protocols/uri/drafts/draft-masinter-url-ipv6-02.txt
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Junk in server's SSL cert date field?
John M. Langley wrote: Prior to last week, this has always returned information in the form of: Certificate valid start date: Oct 31 00:00:00 2002 GMT Certificate valid end date: Oct 30 23:59:59 2004 GMT ***but*** now I'm receiving: Certificate valid start date: Bad time valueludGVybmF0 Certificate valid end date: Bad time value Why won't you send us the contents of the ASN1_TIME *tm? The Bad time value message comes from the ASN1_TIME_print, but try to do the following and send us the results: ASN1_TIME *tm = ...; fwrite(tm-data, 1, tm-length, stdout); -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_set_quiet_shutdown
SSL_set_quiet_shutdown() suppresses sending close notify alert
to the remote party during SSL_shutdown. Shouldn't it also
cause BIO to send resets (0 linger + no shutdown(2)) when
connection is being destroyed? Otherwise, a transaction terminates
with almost correct FIN sequence.
The SSL_set_quiet_shutdown() call allows us to violate the TLS standard,
but does it only half-way. It causes the SSL session to be closed
incorrectly (by the TLS standard) and this meant to be indicative
that the transaction went bad. But the real world applications
(i.e., I.E.) ignore the incorrect SSL terminations, and only
consider connection to be really bad, when the connection is
terminated with RST.
If SSL_set_quiet_shutdown() is augmented to have connection BIO
to _not_ to call shutdown() on such connections.
This way, if an application wishes to destroy SSL connection by
incorrectly terminating the SSL stream, it would have only
to set up SO_LINGER on socket appropriately ({1, 0}), and
call SSL_set_quiet_shutdown().
Otherwise, SO_LINGER with 1/0 settings does not help under
some OSes, because shutdown(, 2) before close() causes FIN
segment to be emitted earlier than RST, thus making the
remote end confused.
On the other hand, one may use BIO_set_close(SSL_get_wbio(), BIO_NOCLOSE)
and close the socket descriptor separately from doing SSL_free().
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
BIO_s_connect memory leak
BIO_s_connect() has a potential memory leak.
When BIO_set_cose(..., BIO_NOCLOSE) is set, the BIO_s_connect will not
dealocate aux data (port and hostname).
=== cut ===
static int conn_free(BIO *a)
{
BIO_CONNECT *data;
if (a == NULL) return(0);
data=(BIO_CONNECT *)a-ptr;
if (a-shutdown)
{
conn_close_socket(a);
BIO_CONNECT_free(data);
a-ptr=NULL;
a-flags=0;
a-init=0;
}
return(1);
}
=== cut ===
The BIO_CONNECT_free() must be moved out of if(a-shutdown) clause.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Oliver Welter wrote: Hello Lev, thx for the quick answer We use openssl to en/decrypt data with 3des - is it possible to retrieve the used key while running a de/encryption via a memory debugger or something similar ? [skip] plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. do you really need a study to believe that? -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Lev Walkin wrote: Oliver Welter wrote: Hello Lev, thx for the quick answer We use openssl to en/decrypt data with 3des - is it possible to retrieve the used key while running a de/encryption via a memory debugger or something similar ? [skip] plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. P.S. I am being unfair to a certain extent. Good security-conscious programming provides several techniques to lower the window of opportunity for the attacker to gain the access to this data. For example, it is customary to wipe the key from the memory after it was used to encrypt the data. The anti-swap techniques (mlockall(2)) are also widely used. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Roberto López Navarro wrote: I think I read something that may help you in the article Playing hide and seek with stored keys by Adi Shamir and Nicko van Someren. The abstract: In this paper we consider the problem of efficiently locating cryptographic keys hidden in gigabytes of data, such as the complete file system of a typical PC. We describe efficient algebraic attacks which can locate secret RSA keys in long bit strings, and more general statistical attacks which can find arbitrary cryptographic keys embedded in large programs. These techniques can be used to apply lunchtime attacks on signature keys used by financial institutes, or to defeat authenticode type mechanisms in software packages. Keywords: Cryptanalysis, lunchtime attacks, RSA, authenticode, key hiding. True it is focus on finding key metarial of filesystems, but nevertheles, it should be a valid approach for memory dumps. You can download it from www.ncipher.com after registration. Whoever reads it, makr sure you realize that locating the key material is vastly different from locating the key material having the piece of encrypted data and posessing the knowledge about the structure of data being encrypted. The last one may be exponentially easier. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #897] Bug Report -- PEM_read and PEM_write functions cause application errors.
Marcus Carey via RT wrote:
Windows 2000
MS VC++ .NET
OpenSSL 0.9.7d 17 Mar 2004
FILE *fp;
X509 *cert;
fp = fopen(SomefFile,r);
cert = PEM_read_X509(fp,NULL,NULL,NULL);
fclose(fp);
I have narrowed it down to the BIO_gets() function.
int BIO_get(BIO *b, char *in, int inl)
{
i=b-method-bgets(b,in,inl); /* This causes an application error - The memory could
not be writting */
return(i);
}
This error also occures with PEM_write functions.
Please use the API correctly:
FILE *fp = fopen(...);
X509 *cert = NULL; /* Do not forget NULL!!! */
cert = PEM_read_X509(fp, cert, NULL, NULL);
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Common Name and IDNA
Gisle Vanem wrote: Lev Walkin [EMAIL PROTECTED] said: No, fnmatch() is fairly portable across Unixes though. Please note that fnmatch() use is against RFC2818. Please explain why. Because *.domain.com shouldn't match abc.def.ghi.domain.com per RFC2818#3.1, as it does with fnmatch(). However, most application programmers, including IE ones, seem to ignore this. But for this reason alone, I don't think my comment should be taken too seriously. It is one of the many discrepancies between RFCs and the real world we have to deal with. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Common Name and IDNA
Joe Orton wrote: On Sat, Jun 12, 2004 at 07:38:42PM +0200, Gisle Vanem wrote: How is the /CN= supposed to be encoded for a host/domain- name using international characters? In some specified charset (utf8?) or in the ASCII Compatible Encoded form? I ask since in an application here (using libidn), I get the subject with X509_get_subject_name() and check the CN (or wildcard mask) against the host I connect to. If they don't match, that's an error. E.g. if I connect to www.troms.no, it's registered in DNS as www.xn--troms-zua.no. Should the CN be the same also? Is it an error to match the CN against www.troms.no too? Guessing beeing liberal is okay... I think it's correct to put the ACE form in the commonName, and that's what applications should compare against. IDNA is after all supposed to be an *application*-layer encoding; at the protocol layer, nothing changes, normal ASCII DNS names are used. This is true at HTTP level as well as at DNS level, so there's no reason why SSL should be special. BTW. is there any function in OpenSSL that can match e.g. x*.foo.com against xxx.foo.com? No, fnmatch() is fairly portable across Unixes though. Please note that fnmatch() use is against RFC2818. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How BN_bin2bn works
Carlos Cabañero wrote: Hi! I'm giving a look to the code of OpenSSL as I'm very interested in RSA encryptation / decryp. specially for a subject called Discrete Math. My problem is that I have to work on an algorithm by myself and, of course, I'm trying to implement and understand some things that OSSL uses like the Arbitrary Precision Numbers (BIGNUM). What I can't understand is how the function BN_bin2bn works (or at least, I know what it does but I think doesn't do it correctly). For example, imagine that I have to transform the string 1234 to the BIGNUM-d (that it's a pointer to a long): Initial params: s = 1234 m = 3 n = 4 i = 1 The initial long l is a 32 bit full of zeros. So then when you do: l=(l8L)| *(s++); I would suspect you start from learning how atoi() works. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Is there ASN.1 convert-tool for openssl ?
Jun Kazama wrote: Dear, Is there convert-tool which changes a ASN.1-text file into a ASN.1-c(MACRO) file and a ASN.1-header(STRUCT) file in openssl-src ? (ex. krb5.asn1 = [convert-tool] = krb5_asn.c krb5_asn.h ) When there is the convert-tool, where is it ? I would like to hear from you. Thanks in advance. I am currently in the middle of developing such a tool. Please try out lionet.info/soft/asn1c-0.8.6.tar.gz -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #838] REQ: Creating a BIO from a FILE* should retain (TEXT) access modes
This one is related tohttp://www.mail-archive.com/[EMAIL PROTECTED]/msg16850.html [EMAIL PROTECTED] via RT wrote: Type: REQ OS: WinNT Version: 0.97c Brief: A text mode FILE* will result in a binary BIO with BIO_set_fp. Descr: This seems to make sense since BIO_set_fp also takes in text mode flags along with the FILE*, but on the PEM_write_xx FILE* fns, there is no way to set the text flag when passing in the FILE*. This has led to garbage (bad newlines) certificates being generated under Win2K with a custom certificate generation utility implemented with OpenSSL. If the generated certs aren't used by a program that tries UNIX and MSDOS newlines, this basically forces the developer to use the BIO routines instead, making the write routines with FILE* useless. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl cert policy handling
Dr. Stephen Henson wrote: On Mon, Feb 23, 2004, Chris Brook wrote: Is there any support in crypto-x509(v3) for certificate policy processing/checking as described in X.509 or PKIX? I had a quick look through the code but did not see anything? Or is it planned since it is required for some of the PKI compliance tests? This gets pretty complex with pathLengthConstraints, Name Constraints, User and Authority Constrained policies. Perhaps someone is planning a contribution. Not that I know of. I was asked about the possibility of adding support by someone last year. After lots of discussions nothing happened. I haven't heard anything more for a couple of months. I could resurrect it if there was sufficient interest. Are we talking about proper checking of ASN.1 subtype constraints, or of something more higher level? -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_i2d_bio
Amar Desai wrote: I want to have OCSP_CERTID field from the OCSP_REQUEST in binary format. I tried to get it using i2d_OCSP_CERTID(bp,certID). When i call this function my program segfaults. I also tried ASN1_i2d_bio(i2d_OCSP_CERTID,bp,unsigned char *) and got same segmentation fault. I am using openssl-0.9.7c on Windows 2000. My code is something like this. OCSP_REQUEST *req; OCSP_CERTID *id = NULL; BIO *bp = NULL,*bio = NULL; req = OCSP_REQUEST_new(); why are ok = OCSP_create_request_new(ctx,req,id); you don't i2d_OCSP_REQUEST_bio(bio,req); This function works fine. //ANS1_i2d_bio(i2d_OCSP_CERTID,bp,(unsigned char *)id); check the i2d_OCSP_CERTID(bp,id); return values? Can someone tell me what am i doing wrong? please type `gdb progname progname.core`, then type `bt` inside the debugger end send the output back. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Need Documentation or Details about openssl configuration file
Kathiravan Velusamy wrote: Hi, I need the detail documentation or helping material about openssl.cnf (Configuration file) which describe use of each directives in that file. The configuration file is used to store various types of information specific to different kinds of functionality of the OpenSSL suite. You can read about the overall structure in the `man 5 config`. The specific uses of this configuration file are described in the appropriate manual pages: man req, man ca, etc. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Class.
S.Mehdi Sheikhalishahi wrote:
Hi All
I want to create a RSA class that have the following
member and methods:
class RSAAgent{
public:
RSA* rsa;
RSASign();
RSAVerify();
RSAEncrypt();
RSADecrypt();
RSAGenerate();
}
Do you know any ready class to use it.
Thanks.
Dear Mr. Sheikhalishahi,
You're writing to the OpenSSL development list, where people discuss
questions related to the development of OpenSSL library. This list is
clearly marked as Not for application development questions!,
(check http://www.openssl.org/support/). Moreover, the language you're
trying to employ to write this piece of code (C++) is not the language
OpenSSL development is based upon.
Please use openssl-users list for the questions related to the usage
of OpenSSL library. Please use other mailing list or newsgroup for
questions related to generic C++ programming.
To answer your question: the OpenSSL library provides several methods
to deal with RSA keys, namely, RSA_public_encrypt, RSA_private_decrypt
and others. You may combine these appropriately and build your own class
out of it:
class RSAAgent {
public:
RSA *rsa;
int RSASign(int type, unsigned char *m, unsigned int m_len,
unsigned char *sigret, unsigned int *siglen) {
::RSA_sign(type, m, m_len, sigret, siglen, rsa);
}
int RSAVerify(int type, unsigned char *m, unsigned int m_len,
unsigned char *sigbuf, unsigned int siglen) {
::RSA_verify(type, m, m_len, sigbuf siglen, rsa);
}
// ... continue as shown above ...
}
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Splits Message Block
S.Mehdi Sheikhalishahi wrote: Hi All I want to use RSA_public_encrypt to encrypt some information but It has restriction on the size of information.I heared that I must use split message block.How can I split message blocks. Please Help me. It is not a good practice to use asymmetric cryptographic algorithms (RSA) for bulk encryption. Better create a random key (say, 128 or 256 bits (16 or 32 bytes)), encrypt your data with that key using symmetrical cipher (Blowfish, AES), then encrypt the key itself using RSA_public_encrypt() and throw the key off. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM inconsistency
Rich Salz wrote: And what OpenSSL calls PEM doesn't have that much to do with Privacy Enhanced Mail... Doesn't it? What is that, then? PEM is dead. It died more than a decade ago. OpenSSL used the boundary format. That's the only thing of PEM that remains. :) /r$ OpenSSL uses it inconsistently though. As you see, I _just_ pointing out the problem specifically related with boundary recognition of this boundary format. This has nothing to do with the full PEM semantics as it is given in that RFC, and it has more to do with interoperability, i.e. treating \n and \r equally [well]. Please, let's end this meaningless discussion: either there is a problem with boundary recognition (as confirmed by Richard Levitte), or there isn't. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PEM inconsistency
RFC1421 says:
PEM canonicalization assures that the message text is represented
with the ASCII character set and CRLF line delimiters
...
Two encapsulation boundaries (EB's) are defined for delimiting
encapsulated PEM messages and for distinguishing encapsulated PEM
messages from interspersed (non-PEM) text. The pre-EB is the string
-BEGIN PRIVACY-ENHANCED MESSAGE-, indicating that an
encapsulated PEM message follows. The post-EB is either (1) another
pre-EB indicating that another encapsulated PEM message follows, or
(2) the string -END PRIVACY-ENHANCED MESSAGE- indicating
that any text that immediately follows is non-PEM text.
And the code in crypto/pem/pem_lib.c does not honor these agreements:
=== cut1 ===
if (strncmp(buf,-BEGIN ,11) == 0)
{
i=strlen((buf[11]));
if (strncmp((buf[11+i-6]),-\n,6) != 0)
continue;
=== cut ===
=== cut2 ===
i=strlen(nameB-data);
if ((strncmp(buf,-END ,9) != 0) ||
(strncmp(nameB-data,(buf[9]),i) != 0) ||
(strncmp((buf[9+i]),-\n,6) != 0))
{
PEMerr(PEM_F_PEM_READ_BIO,PEM_R_BAD_END_LINE);
goto err;
}
=== cut ===
This code is written with expectations that the line is terminated
by LF in Unix-style, and effectively prohibits this code to be used
in DOS/MAC, unless some external entity pre-processes the input data
to strip/replace CR's with LF's.
If I am reading it correctly, the PEM encoding must work even in
the following case (ignore double quotes):
-BEGIN SOMETHING-abcd=-END SOMETHING-
and the PEM code in OpenSSL prohibits such form.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: PEM inconsistency
Dr. Stephen Henson wrote: On Mon, Dec 22, 2003, Rich Salz wrote: RFC1421 says: ... Two encapsulation boundaries (EB's) are defined for delimiting encapsulated PEM messages and for distinguishing encapsulated PEM You can't read that alone; read the previous paragraph which references RFC 934; the boundaries are line-based. As for \r\n vs \n, OpenSSL follows the ANSI/ISO C standard which makes \n be the line-ending character. Under Windows/DOS, etc., make sure to open your files in text (not binary) mode. And what OpenSSL calls PEM doesn't have that much to do with Privacy Enhanced Mail... Doesn't it? What is that, then? -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM inconsistency
Rich Salz wrote: RFC1421 says: ... Two encapsulation boundaries (EB's) are defined for delimiting encapsulated PEM messages and for distinguishing encapsulated PEM You can't read that alone; read the previous paragraph which references RFC 934; the boundaries are line-based. Indeed, it is true. By the way BNF says it more clear than this paragraph: === 9. Descriptive Grammar === preeb ::= -BEGIN PRIVACY-ENHANCED MESSAGE- CRLF posteb ::= -END PRIVACY-ENHANCED MESSAGE- CRLF / preeb === cut === Which, by the way, has an additional property of supporting my original point: even on Unix, if you open a file with CRLF line termination in a text mode, you'll end up with \r\n, but not \n, which is [wrongly] expected by the parser (the code I've cited). btw, this might also be of interest: === 4.6.1.1.3 A case of particular relevance arises for inbound SMTP processing on systems which delimit text lines with local native representations other than the SMTP-conventional CRLF. When mail is delivered to a UA on such a system and presented for PEM processing, the CRLF has already been translated to local form. In order to validate a MIC-CLEAR message's MIC in this situation, the PEM module must recanonicalize the incoming message in order to determine the inter- SMTP representation of the canonically encoded message (as defined in Section 4.3.2.2 of this RFC), and must compute the reference MIC based on that representation. === Generally, it says that PEM processor must recanonizalize the input data before processing. In Unix, make \n - \r\n map, and process the message only after that. I am not advocating for that, as it is obviously superfluous, but it may be understood just as the PEM parsing must be prepared to accept both CR, CRLF and LF forms. As for \r\n vs \n, OpenSSL follows the ANSI/ISO C standard which makes \n be the line-ending character. Under Windows/DOS, etc., make sure to open your files in text (not binary) mode. /r$ -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Memory leak in pem_lib.c
The following code produces a memory leak if a memory allocation fails
intermittenly:
=== cut from pem_lib.c ===
nameB=BUF_MEM_new();
headerB=BUF_MEM_new();
dataB=BUF_MEM_new();
if ((nameB == NULL) || (headerB == NULL) || (dataB == NULL))
{
PEMerr(PEM_F_PEM_READ_BIO,ERR_R_MALLOC_FAILURE);
return(0);
}
=== cut ===
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: PEM manual page error
Dr. Stephen Henson wrote: And 3. Applications shouldn't call PEM_read_bio() themselves. Unfortunately, this is pretty much the only choice when it comes to the ability to PEM-encode something specific to the application. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #800] EVP_CipherUpdate usage is incorrect in EVP_EncryptInit(3)
The manual page on EVP_EncryptInit contains the incorrect usage case for
EVP_CipherUpdate.
If EVP_CipherUpdate() fails, the caller is still supposed to invoke a
EVP_CIPHER_CTX_cleanup() function. In this example taken from the manual
page, the function just returns with 0 error code right when the
EVP_CipherUpdate fails without doing so.
=== cut ===
EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, do_encrypt);
for(;;)
{
inlen = fread(inbuf, 1, 1024, in);
if(inlen = 0) break;
if(!EVP_CipherUpdate(ctx, outbuf, outlen, inbuf,
inlen)
)
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
}
if(!EVP_CipherFinal_ex(ctx, outbuf, outlen))
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
EVP_CIPHER_CTX_cleanup(ctx);
return 1;
}
=== cut ===
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #801] Memory leak in pem_lib.c
The following code produces a memory leak if a memory allocation fails
intermittenly:
=== cut from pem_lib.c ===
nameB=BUF_MEM_new();
headerB=BUF_MEM_new();
dataB=BUF_MEM_new();
if ((nameB == NULL) || (headerB == NULL) || (dataB == NULL))
{
PEMerr(PEM_F_PEM_READ_BIO,ERR_R_MALLOC_FAILURE);
return(0);
}
=== cut ===
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: PEM manual page error
Dr. Stephen Henson wrote: On Sat, Dec 20, 2003, Lev Walkin wrote: Dr. Stephen Henson wrote: And 3. Applications shouldn't call PEM_read_bio() themselves. Unfortunately, this is pretty much the only choice when it comes to the ability to PEM-encode something specific to the application. Most applications wouldn't need to do that and it would be creating something non standard in any case. Indeed. Hovewer, everything standard is already created, so why bother programming at all? ;) -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PEM manual page error
The PEM(3) manual page specifies a way to read a certificate in PEM format
from a BIO:
=== cut ===
Although the PEM routines take several arguments in almost
all applications most of them are set to 0 or NULL.
Read a certificate in PEM format from a BIO:
X509 *x;
x = PEM_read_bio(bp, NULL, 0, NULL);
if (x == NULL)
{
/* Error */
}
=== cut ===
It is erroneous and misleading because
1. There is no PEM_read_bio() function described in that manual page.
2. The actual PEM_read_bio() declaration is
int PEM_read_bio(BIO *bp, char **name, char **header, unsigned char **data,
long *len);
which does not have the semantics compatible with the usage case wshown
in the manual page.
Surprisingly though, if there is no -BEGIN sequence in the provided
BIO pointer bp, the PEM_read_bio() _will_ return 0, and x==NULL will be
evaluated to true. Hovewer, if bp contains the valid PEM data, the program
will just crash because of unchecked
*name=nameB-data;
in the PEM_read_bio() implementation.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
EVP_CipherUpdate usage is incorrect in EVP_EncryptInit(3)
The manual page on EVP_EncryptInit contains the incorrect usage case for
EVP_CipherUpdate.
If EVP_CipherUpdate() fails, the caller is still supposed to invoke a
EVP_CIPHER_CTX_cleanup() function. In this example taken from the manual
page, the function just returns with 0 error code right when the
EVP_CipherUpdate fails without doing so.
=== cut ===
EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, do_encrypt);
for(;;)
{
inlen = fread(inbuf, 1, 1024, in);
if(inlen = 0) break;
if(!EVP_CipherUpdate(ctx, outbuf, outlen, inbuf,
inlen)
)
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
}
if(!EVP_CipherFinal_ex(ctx, outbuf, outlen))
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
EVP_CIPHER_CTX_cleanup(ctx);
return 1;
}
=== cut ===
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: bn_lib.c:bn_expand2()
Geoff Thorpe wrote: Hi Andy (and anyone else that's interested), As part of the general hackathon/audit we're doing in crypto/bn/ I once again came across the curious zeroing code in bn_expand2, only this time I figured it was high time for me to actually ask you about it. :-) I understand the desire to cater for CPU pipelining with the 8-wise loop unrolling, but is this a better solution than just using memset() and letting the compiler take care of the same sort of thing? It's #ifdef'ed already, so you may've as well tried it out and check performance with profiler. Generally, there is nothing could be said about such optimizations. It so heavily depends on the platform (compiler + libc + hardware arch) that no useful conclusions may be drawn from just looking at the code. Even if profiling would show you that memset() is faster, it may be by order of magnitude slower on the machine very next to you (which has different version of C library or different compiler settings). Particularly, the considerations about precisely that internal loop vs. memset() are that: 1. memset MAY invoke a function call to the area which (1) MAY not be readily available in the cache and (2) the call itself takes so much CPU time that it would be possible to move a handful of BN_ULONG's instead. 2. if memset() is inlined, the particular implementation MAY perform some computations and byte-to-byte moves to align data on proper boundaries for further word-by-word copying. This may as well be less optimal than doing T *A = T *B, where T is a word. 3. Note that this loop moves 16 bytes per loop, compared to 4 bytes per loop in typical memset() implementations on x86. It has slightly higher cost per loop though (i--, A+=4, B+=4) and a pointer subscription (instead of dereferencing, this alone would be about 30% faster). Bottom line: try it out. P.S. any way, the optimization in this part will be completely negligible compared to the other costs, like encryption. Note, I'm not going to mess with this code myself, partly because I don't know the full history behind it and partly because this sort of thing is not really the focus for me at the moment. I'm just querying out of interest. TIA. Cheers, Geoff -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: about the sequence number field
Swaminathan P wrote: hi, thanks for your quick reply. So if I can include the sequence number as a part of the protocol(may be another field added by the SSL) data, I still solve the problem of replay attacks and I can get rid of sequence number from the MAC calculation. So my MAC wouldnt depend on the sequence number now. Basically, you're a) adding a piece (8 bytes in TLS) of predictable data into the byte stream sequence (making it a tiny bit easier for the symmetric key attack) and b) adding additional several bytes to the overall length of the data record (as opposed to have it melt into the fixed-size MAC). To avoid replay attacks there are 2 options: 1. As it exists now. MAC would fail with duplicate packets. 2. Or if sequence number is made a part of the protocol and stripped of the MAC calulation, I can verify and avoid duplicate packets from the sequence number which could be made a part of the protocol data (even though the MAC would succeed). This is just as the way TCP works. If I'm wrong in any of these points please do correct me. More or less true. But what are you really achieving by this besides loosing several bytes by having to extend a record? The protocol specifies that the MAC should be applied over unencrypted message, than an encryption should proceed over the message and the MAC. By having the sequence inside the data you're trying to make it closer to the attacker while making a thing to take longer to encrypt (because the message is longer). Thanks again Lev for your quick reply. -swami On Wed, 19 Nov 2003, Lev Walkin wrote: Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? Sequence number prevents replay attacks. Both sides of SSL communication channel are keeping track of number of messages received. If somebody has ability to inject a record into the SSL stream which is the same as some other record observed on that stream, the sequence number melted in a MAC will prevent the SSL machinery to treat this record as a valid one. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Header games.
This is really a very small issue, but it bothers us for quite a while. The x509.h file contains the prototype for two RSA-related functions, RSAPublicKey_dup() and RSAPrivateKey_dup(). Being included into the source file with the rsa.h header, the double definition clashes with the one defined in rsa.h, which creates a problem if the codebase for external project is supposed to be compiled with -Werror and additional prototype checking (which is quite paranoid, but such is life). I am not sure whether the proposed change (to remove these declarations from x509.h) is safe enough to be considered (from the perspective of breaking compatibility with some existing software), but it seems to be a small step into right direction. === cut === --- ./crypto/x509/x509.hTue Nov 11 15:36:17 2003 +++ ./crypto/x509/x509.hTue Nov 11 15:35:50 2003 @@ -810,9 +810,11 @@ X509_ALGOR *X509_ALGOR_dup(X509_ALGOR *xn); X509_NAME *X509_NAME_dup(X509_NAME *xn); X509_NAME_ENTRY *X509_NAME_ENTRY_dup(X509_NAME_ENTRY *ne); +#if 0 /* Redundant declarations: openssl/rsa.h already has it. */ #ifndef OPENSSL_NO_RSA RSA *RSAPublicKey_dup(RSA *rsa); RSA *RSAPrivateKey_dup(RSA *rsa); +#endif /* OPENSSL_NO_RSA */ #endif #endif /* !SSLEAY_MACROS */ --- ./include/openssl/x509.hMon Nov 10 12:41:34 2003 +++ ./include/openssl/x509.hMon Nov 10 12:34:54 2003 @@ -810,9 +810,11 @@ X509_ALGOR *X509_ALGOR_dup(X509_ALGOR *xn); X509_NAME *X509_NAME_dup(X509_NAME *xn); X509_NAME_ENTRY *X509_NAME_ENTRY_dup(X509_NAME_ENTRY *ne); +#if 0 /* Redundant declarations: openssl/rsa.h already has it. */ #ifndef OPENSSL_NO_RSA RSA *RSAPublicKey_dup(RSA *rsa); RSA *RSAPrivateKey_dup(RSA *rsa); +#endif /* OPENSSL_NO_RSA */ #endif #endif /* !SSLEAY_MACROS */ === cut === -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Header games.
Geoff Thorpe wrote: Hey Lev, On November 18, 2003 08:28 pm, Lev Walkin wrote: This is really a very small issue, but it bothers us for quite a while. Which version are you seeing this in? IIRC, I corrected this same clash in CVS. 0.9.7c. But I've been seeing that in virtually all older versions. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
