Jitendra Lulla | 29 Jul 13:09 2014
Picon

Re: Need guidance to replace HMAC-SHA1 implementation via engine

Hi Steve,

Please refer the following mail from you:

http://www.mail-archive.com/openssl-dev%40openssl.org/msg32918.html

"...
The high level MAC (including HMAC) interfaces go through EVP_PKEY treating it
as a signing operation. It *is* possible to redirect HMAC in that way but only
if the application uses the EVP_PKEY MAC interface. Anything using the HMAC_*
functions directly wont use the ENGINE.

There is a big gotcha though. The "lucky 13" attack fix had to bypass EVP
entirely and reimplement HMAC (and SSLv3 MAC) in constant time. That means
that the record MAC operations for SSL/TLS can no longer be redirected through
an ENGINE. At some point this will be addressed but it requires support at the
ENGINE (and associated hardware) too: to implement the appropriate constant
time algorithms.

Steve
.."

could you please help me find the changeset that fixed the lucky 13 attack?
I am in need of testing my engine which is supposed to take care of the following command:
./openssl dgst -engine af_alg -sha1 -mac hmac -macopt hexkey:f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff data_32.txt

The command gives the correct hmac but without going through the engine!
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
(Continue reading)

Harendra Rawat via RT | 29 Jul 03:58 2014
Picon

[openssl.org #3176]

Deadlock still persists with 1.0.1h with fips mode not set.

fips_drbg_bytes() 
 CRYPTO_w_lock(CRYPTO_LOCK_RAND) 
 FIPS_drbg_generate() 
  drbg_reseed() 
   fips_get_entropy() 
    drbg_get_entropy() 
     ssleay_rand_bytes() 
      CRYPTO_w_lock(CRYPTO_LOCK_RAND) 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Harendra Rawat via RT | 29 Jul 03:56 2014
Picon

[openssl.org #3127]

Hi 

I see deadlock happening with 1.0.1h as well without fips mode.

fips_drbg_bytes() 
 CRYPTO_w_lock(CRYPTO_LOCK_RAND) 
 FIPS_drbg_generate() 
  drbg_reseed() 
   fips_get_entropy() 
    drbg_get_entropy() 
     ssleay_rand_bytes() 
      CRYPTO_w_lock(CRYPTO_LOCK_RAND) 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Pavel Semjanov | 28 Jul 11:48 2014

AES_cbc_encrypt & aesni_cbc_encrypt length parameter

Hello,

I was absolutely sure that parameters of all AES functions are 
equivalent in all implementations. However, I found that
AES_cbc_encrypt and aesni_cbc_encrypt differ in length parameter if it's 
not a multiple of 16. For example,
AES_cbc_encrypt (in, out, 15, ... ) is returning 15 bytes in out buffer, but
aesni_cbc_encrypt (in, out, 15, ...) is returning only 1 byte.

I looked into the aesni-x86.pl code, and found the strange lines:
     &mov    ("ecx",16);        # zero tail
     &sub    ("ecx",$len);

That's why the output length is always (16-len). I'm not sure this is a 
bug, but I can't find a good reason why the length is changed here.
By the way, vpaes routines can't accept length if it's not a multiple of 
16 at all.

--

-- 

    SY / C4acT/\uBo             Pavel Semjanov
    _   _         _        http://www.semjanov.com
   | | |-| |_|_| |-|

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

(Continue reading)

Stephen Henson via RT | 27 Jul 15:56 2014
Picon

[openssl.org #3476] Faulting module name: libeay32.dll, version: 1.0.1.8, time stamp: 0x539303fb

On Fri Jul 25 12:22:51 2014, David.Wingerson <at> navigant.com wrote:
> This was present only since the new binaries provided to address heart
> bleed there are others having challenges with this. It seems
> somehow related to vmware possibly here is the original thread.
>
> https://forum.filezilla-
> project.org/viewtopic.php?f=6&t=32837&p=124817#p124817
>

It's not clear (to me at least) what the cause is from that information. As a
temporary measure you could try downgrading the version of libeay32.dll ONLY to
1.0.1f to see if that fixes your problem. The critical security fixes are in
ssleay32.dll so you'd still get those.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Stephen Henson via RT | 27 Jul 15:30 2014
Picon

[openssl.org #3469] problem with commit 3009244da47b989c4cc59ba02cf81a4e9d8f8431 - global_mask needs to be more liberal

On Mon Jul 21 20:29:47 2014, v13 <at> v13.gr wrote:
>
> I'm not sure whether this change is needed at all as there's no
> justification
> for it.

The justification is in RFC3280 et al:

"The UTF8String encoding [RFC 2279] is the preferred encoding, and all
certificates issued after December 31, 2003 MUST use the UTF8String
encoding of DirectoryString (except as noted below)."

So in that sense OpenSSL was a bit behind the times. The configuration files
were set to use UTF8 only well before then but not the default in the source.

The bug is in any software which relies on the DirectoryString being a
PrintableString and not in OpenSSL.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Rich Salz via RT | 26 Jul 23:20 2014
Picon

[openssl.org #1850] Bug Report--openssl crashes at SSL_write()

Most likely pointer problems in the application code.
Cannot reproduce this.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Rich Salz via RT | 26 Jul 23:15 2014
Picon

[openssl.org #1789] BUG: openssl verify command does not report signature error if there are other errors

Working as designed: no verification until a valid trust path is found.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Rich Salz via RT | 26 Jul 23:13 2014
Picon

[openssl.org #1764] openssl-0.9.8i random generator bug

no response in years, assuming the diagnosis is right. closing this.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Rich Salz via RT | 26 Jul 23:09 2014
Picon

[openssl.org #1737] [PATCH openssl 0.9.8g] s_client: add sieve starttls protocol support

Is SIEVE used much?
Is it worth adding to s_client?

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Rich Salz via RT | 26 Jul 23:06 2014
Picon

[openssl.org #1733] Facing problem with ssleay.dll

Old release, unsufficient information, can't reproduce, closing.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org


Gmane