headers
Larry Shores via RT | 1 Aug 2006 07:20
Picon
Favicon

[openssl.org #1192] OPENSSL S_CLIENT STARTTLS SMTP PATCH


vijay, if this is you  write me back  larry.shores <at> adelphia.net
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Andy Polyakov | 1 Aug 2006 09:33
Picon
Picon

AES performance vs. security

Latest development snapshot has updated AES x86 assember module, which 
trades performance for security for all encryption modes, but CBC. 
Encrypt performance is about 1/2 original assembler and decrypt - about 
1/3. Note that you won't notice performance degradation in 'openssl 
speed aes' output, use 'openssl speed -evp aes-128-ecb [-decrypt]' to 
benchmark new code. CBC procedure needs further work and shall switch to 
slower block routine when asked to process smaller amount of data or 
when executed on hyper-threading CPU. Detecting hyper-threading CPU 
presents a challenge as it can't be done by looking at CPUID output. One 
can identify HT-capable P4, but not if it's actually hyper-threading. 
I'm open for suggestions... A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 1 comment |
headers
Yang, Chul-Woong | 1 Aug 2006 12:07
Picon

Q) SMP-safeness about i2d_X509() call

Dear Sirs,

As I read OpenSSL 0.9.8b source tree,
I found that i2d_X509() may call x509_name_encode(),
which can modify common data structure (certificate data),
without locking.

Because many SSL I/O function call ssl3_send_server_certificate() in
handshaking phase, I worry that this may severely broke
concurrency.

CPU0:
ssl3_accept =>
ssl3_send_server_certificate =>
ssl3_output_cert_chain (common cert with CPU1) =>
...
=> x509_name_encode
=> BUF_MEM_grow (manipulate common cert)

CPU1:
ssl3_accept =>
ssl3_send_server_certificate =>
ssl3_output_cert_chain (common cert with CPU0) =>
...
=> x509_name_encode
=> BUF_MEM_grow (manipulate common cert)

Is my view right? If so, what's best approach to resolve this issue?

Any comments are welcomed.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dr. Stephen Henson | 1 Aug 2006 14:22
Picon
Favicon

Re: Q) SMP-safeness about i2d_X509() call

On Tue, Aug 01, 2006, Yang, Chul-Woong wrote:

> Dear Sirs,
> 
> As I read OpenSSL 0.9.8b source tree,
> I found that i2d_X509() may call x509_name_encode(),
> which can modify common data structure (certificate data),
> without locking.
> 
> Because many SSL I/O function call ssl3_send_server_certificate() in
> handshaking phase, I worry that this may severely broke
> concurrency.
> 
> CPU0:
> ssl3_accept =>
> ssl3_send_server_certificate =>
> ssl3_output_cert_chain (common cert with CPU1) =>
> ...
> => x509_name_encode
> => BUF_MEM_grow (manipulate common cert)
> 
> CPU1:
> ssl3_accept =>
> ssl3_send_server_certificate =>
> ssl3_output_cert_chain (common cert with CPU0) =>
> ...
> => x509_name_encode
> => BUF_MEM_grow (manipulate common cert)
> 
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
k b | 2 Aug 2006 02:04
Picon
Favicon

Sha1 hash differs

Hi,
here's what i'm doing,  i comparing the sha1 hash generated with the  
command line tool
#>openssl sha1 -out digest.txt -binary smallplaintxt
against the one created by my c program.
i load both the hash using hexedit to see if they are the same but to my 
surprise they differ.

here's what i'm doing in my c file.

#define DATA_SIZE_IN_BYTES  5

int main (int argc, char *argv[])
{
  SHA_CTX shaCTX;
  static unsigned char hash[SHA_DIGEST_LENGTH];
  char * generateHashFile = argv[1];

  if (!SHA_Init(&shaCTX)) {
    return -1;
  }

  char *data = (char *) readPlainText();

  printf("length %d, %s\n", strlen(data), data);
  SHA_Update(&shaCTX, data, (sizeof(char) * DATA_SIZE_IN_BYTES));
  SHA_Final(hash, &shaCTX);
  OPENSSL_cleanse(&shaCTX, sizeof(shaCTX));

  FILE *fp;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mounir IDRASSI | 2 Aug 2006 02:38
Favicon
Gravatar

Re: Sha1 hash differs

Hi,
The problem comes certainly from the line calling SHA_Update : you are 
always hashing  DATA_SIZE_IN_BYTES byte of data but the command line 
tool hashes only the exact length of the file. You should replace 
DATA_SIZE_IN_BYTES with strlen(data) .

Cheers,

Mounir IDRASSI
IDRIX
http://www.idrix.net

k b a écrit :
> Hi,
> here's what i'm doing,  i comparing the sha1 hash generated with the  
> command line tool
> #>openssl sha1 -out digest.txt -binary smallplaintxt
> against the one created by my c program.
> i load both the hash using hexedit to see if they are the same but to 
> my surprise they differ.
>
> here's what i'm doing in my c file.
>
> #define DATA_SIZE_IN_BYTES  5
>
> int main (int argc, char *argv[])
> {
>  SHA_CTX shaCTX;
>  static unsigned char hash[SHA_DIGEST_LENGTH];
>  char * generateHashFile = argv[1];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Girish Venkatachalam | 2 Aug 2006 03:50
Picon
Favicon

Re: Sha1 hash differs


--- k b <k_bisla <at> hotmail.com> wrote:

> Hi,
> here's what i'm doing,  i comparing the sha1 hash
> generated with the  
> command line tool
> #>openssl sha1 -out digest.txt -binary smallplaintxt
> against the one created by my c program.
> i load both the hash using hexedit to see if they
> are the same but to my 
> surprise they differ.
> 
> here's what i'm doing in my c file.
> 
> #define DATA_SIZE_IN_BYTES  5
> 
> int main (int argc, char *argv[])
> {
>   SHA_CTX shaCTX;
>   static unsigned char hash[SHA_DIGEST_LENGTH];
>   char * generateHashFile = argv[1];
> 
>   if (!SHA_Init(&shaCTX)) {
>     return -1;
>   }
> 
>   char *data = (char *) readPlainText();
> 
>   printf("length %d, %s\n", strlen(data), data);
(Continue reading)

Permalink | Reply | 1 comment |
headers
k b | 2 Aug 2006 17:25
Picon
Favicon

Re: Sha1 hash differs

Thanks Girish, that was indeed the problem.

>From: Girish Venkatachalam <girish1729 <at> yahoo.com>
>Reply-To: openssl-dev <at> openssl.org
>To: openssl-dev <at> openssl.org
>Subject: Re: Sha1 hash differs
>Date: Tue, 1 Aug 2006 18:50:49 -0700 (PDT)
>
>
>
>--- k b <k_bisla <at> hotmail.com> wrote:
>
> > Hi,
> > here's what i'm doing,  i comparing the sha1 hash
> > generated with the
> > command line tool
> > #>openssl sha1 -out digest.txt -binary smallplaintxt
> > against the one created by my c program.
> > i load both the hash using hexedit to see if they
> > are the same but to my
> > surprise they differ.
> >
> > here's what i'm doing in my c file.
> >
> > #define DATA_SIZE_IN_BYTES  5
> >
> > int main (int argc, char *argv[])
> > {
> >   SHA_CTX shaCTX;
> >   static unsigned char hash[SHA_DIGEST_LENGTH];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Polyakov | 2 Aug 2006 18:04
Picon
Picon

Re: AES performance vs. security

> Latest development snapshot has updated AES x86 assember module,

As it turns out there is a breakage point. As you might have noticed the 
module expects S-box tables to be aligned with 1024 byte granularity. 
While it doesn't seem to be a problem to ensure such alignment on ELF 
platforms, others seem to fail to arrange it. For example a.out-based 
OpenBSD 3.2 allows you to specify up to 32K alignment, but it's 
apparently ignored somewhere, as it doesn't seem to have effect on 
symbol alignment in final executable. Win32 is complete mess. Microsoft 
PECOFF specification allows for alignment up to 8KB, but Microsoft 
assembler does not allow alignment statements over 256 bytes [even if I 
specify TEXT$ SEGMENT PAGE]. nasm refuses segment alignment larger than 
64 bytes claiming that the specification does not allow for more. yasm 
seem to be the only one doing right thing, and good news is that even 
elder Microsoft linker, version 6 to be specific, respects the alignment 
specified by yasm and the table turns out properly aligned in final 
executable. Cygwin and Mingw binutils don't seem to be helpful at all 
silently assuming 16 byte alignment on everything. Well, they use align 
statement for padding, but not for actual alignment. Bottom line, some 
further consideration and work is required... A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Vladislav Wainbaum | 2 Aug 2006 19:24
Picon

"Conformance testing..." tests coverage

A change named "Preliminary support for certificate policy evaluation
and checking. This is initially intended to pass the tests outlined in
"Conformance Testing of Relying Party Client Certificate Path
Processing Logic" v1.07." had been made in openssl-0.9.8, according to
the change log.

Is the mentioned tests are completely covered with openssl-0.9.8b?
If not, could you please to specify known problems?

Thank you,
Vlad
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 1 comment |

Gmane