It seems like this fine-grained level of detail may have been more
suitable for an earlier point in time when the subcomponents were used.
With the advent of shared libraries, there is less motivation to split
things up in that way, and perhaps the decision to have separate version
strings for
We strictly need use our custom paramsets for GOST algorithms (all of cipher,
hash and signature,
including X509 and TLS). If most of the functionality may be implemented by
dirty overriding
initialization methods, X509 requires ccgost engine sources patching.
Seems 2 ways:
1. Put our paramsets
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote:
This code does open-coded division on 64-bit quantities and thus when
building with GCC on 32-bit platforms will require functions such as
__umoddi3 and __udivdi3 from libgcc.
In constrained environments such as
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote:
This code does open-coded division on 64-bit quantities and thus when
building with GCC on 32-bit platforms will require functions such as
__umoddi3 and __udivdi3 from libgcc.
In constrained environments such as
The SHA-3 standard seems to be out:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
Kurt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Considering emerging attacks against UEFI I'd be hesitant weakening protection
mechanisms, even those that *currently* aren't likely to be used.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
Original Message
From: David Woodhouse via RT
Sent: Friday, August 7,
On Fri, 2015-08-07 at 08:58 +, Ben Laurie via RT wrote:
I am curious why you think you don't need CT for UEFI?
The use case for OpenSSL within UEFI is for Secure Boot — checking
PKCs#7 signatures on bootloader / operating system images.
Referring to RFC6962...
Abstract
This document
Original Message
From: Blumenthal, Uri - 0553 - MITLL via RT
Sent: Friday, August 7, 2015 11:52 AM
To: dw...@infradead.org
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed
Certificate Timestamps to be
Original Message
From: Blumenthal, Uri - 0553 - MITLL via RT
Sent: Friday, August 7, 2015 11:52 AM
To: dw...@infradead.org
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed
Certificate Timestamps to be
Hi,
In ./Configure, there is this comment:
# big-endian platform. This is because ARMv7 processor always
# picks instructions in little-endian order. Another similar
# limitation is that -mthumb can't cross -march=armv6t2
# boundary, because that's where it
From a15e06fa9600aecfee8fead41c2f47e052958d12 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 7 Aug 2015 16:47:10 +0100
Subject: [PATCH] Allow scrypt to be disabled
This does 64-bit division and multiplication, and on 32-bit platforms
pulls in libgcc symbols
Considering emerging attacks against UEFI I'd be hesitant weakening protection
mechanisms, even those that *currently* aren't likely to be used.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
Original Message
From: David Woodhouse via RT
Sent: Friday, August 7,
I asked about this before but no one answered. :(
On Aug 7, 2015 1:54 AM, Kurt Roeckx k...@roeckx.be wrote:
The SHA-3 standard seems to be out:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
Kurt
___
openssl-dev mailing list
To
On Fri, 2015-08-07 at 08:58 +, Ben Laurie via RT wrote:
I am curious why you think you don't need CT for UEFI?
The use case for OpenSSL within UEFI is for Secure Boot — checking
PKCs#7 signatures on bootloader / operating system images.
Referring to RFC6962...
Abstract
This document
Updated patch. I had hoped to cope with the setting of SIXTY_FOUR_BIT
vs. THIRTY_TWO_BIT with nasty tricks, but those didn't work.
For the EDKII build we can't configure OpenSSL separately for the
specific architecture and toolchain we're using. People might be
building on Windows and not even
Updated patch. I had hoped to cope with the setting of SIXTY_FOUR_BIT
vs. THIRTY_TWO_BIT with nasty tricks, but those didn't work.
For the EDKII build we can't configure OpenSSL separately for the
specific architecture and toolchain we're using. People might be
building on Windows and not even
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
Considering emerging attacks against UEFI I'd be hesitant weakening
protection mechanisms, even those that *currently* aren't likely to
be used.
Can you suggest a practicable means by which this *could* be used?
--
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
Considering emerging attacks against UEFI I'd be hesitant weakening
protection mechanisms, even those that *currently* aren't likely to
be used.
Can you suggest a practicable means by which this *could* be used?
--
Alas, not right now (and here we're in agreement).
However I expect the field to evolve with the threats, and the means for using
this capability to emerge. IMHO it would be easier to keep this feature waiting
rather than opening a whole new discussion later on. Plus, by just being there
it
Alas, not right now (and here we're in agreement).
However I expect the field to evolve with the threats, and the means for using
this capability to emerge. IMHO it would be easier to keep this feature waiting
rather than opening a whole new discussion later on. Plus, by just being there
it
Hi,
I made two pull requests to openssl:
https://github.com/openssl/openssl/pull/364
https://github.com/openssl/openssl/pull/367
Ismo Puustinen ismo.puusti...@intel.com
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
21 matches
Mail list logo
