On Thu, Oct 06, 2022 at 05:09:21PM +, John Gray wrote:
> For a use case like an HSM or TPM where private keys can never leave
> rules out option 1 (plus who wants to send their private key anyway
> unless it is for server backup or escrow purposes). Option 3 would
> work but is bad for CT log
On Fri, Jul 03, 2020 at 05:45:22PM +, Jordan Brown wrote:
> On 7/3/2020 6:03 AM, Marc Roos wrote:
> > Also hypocrite of Akamai, looking at the composition of the executive team.
>
> I think it's pretty clear that Rich was speaking as himself, not as a
> representative of Akamai.
Hi Jordan,
On Thu, Dec 17, 2015 at 09:28:28AM +, Salz, Rich wrote:
> I want to change the memory alloc/debug things.
>
> Right now there are several undocumented functions to allow you to
> swap-out the malloc/realloc/free routines, wrappers that call those
> routines, debug versions of those wrappers,
On Thu, Dec 17, 2015 at 08:16:50PM +, Salz, Rich wrote:
> > > https://github.com/openssl/openssl/pull/450
> >
> > This seems much more sane.
>
> I'll settle for less insane :)
That is, I think, the best you can do. Some allocations might have
taken place by the time a wrapper or
On Tue, Jun 16, 2015 at 12:51:31PM +0530, Atul Thosar wrote:
Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc)
and it works well on Solaris 10 platform. We use Sun Studio 12 compiler.
We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o
changing
I should add that you should read all the release notes of every update
and check if your product would be affected.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
We're closer.
On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
On 13/05/2015 17:46, Nico Williams wrote:
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
On 12/05/2015 21:45, Nico Williams wrote:
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
How about
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
On 12/05/2015 21:45, Nico Williams wrote:
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
How about the following simplifications for the new
extension, lets call it GSS-2 (at least in this e-mail).
1. GSS (including
I wonder if we could do this in the KITTEN WG list. Maybe not every
extension to TLS needs to be treated as a TLS WG work item... We should
ask the security ADs.
Nico
--
___
openssl-users mailing list
To unsubscribe:
I should add that I prefer a protocol that optimizes the GSS round trips
over one that doesn't, though that means using SPNEGO for negotiation
(when negotiation is desired).
___
openssl-users mailing list
To unsubscribe:
On Tue, May 12, 2015 at 06:10:39PM +, Salz, Rich wrote:
You can't easily have test vectors for DSA signatures since they
include a random. Any test vector would have to include the random,
and any API would have to be able to accept the random as part of the
sign API. Verification should
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
How about the following simplifications for the new
extension, lets call it GSS-2 (at least in this e-mail).
1. GSS (including SASL/GS2) is always done via the SPNego
GSS mechanism, which provides standard handling of
mechanism
On Mon, May 11, 2015 at 04:42:49PM +, Viktor Dukhovni wrote:
On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:
- If you don't want to depend on server certs, use anon-(EC)DH
ciphersuites.
Clients and servers must reject[*] TLS connections using
On Fri, May 08, 2015 at 10:57:52PM -0500, Nico Williams wrote:
I should have mentioned NPN and ALPN too.
[...]
A few more details:
- If you don't want to depend on server certs, use anon-(EC)DH
ciphersuites.
Clients and servers must reject TLS connections using such a
ciphersuite
On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote:
I agree that the current situation is not sustainable. I was only
hoping to start a conversation about how to improve the situation.
RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT
intended for use outside
I should have mentioned NPN and ALPN too.
A TLS application could use ALPN to negotiate the use of a variant of
the real application protocol, with the variant starting with a
channel-bound GSS context token exchange.
The ALPN approach can optimize the GSS mechanism negotiation, at the
price of
On Fri, Aug 23, 2013 at 1:12 AM, Patrick Pelletier
c...@funwithsoftware.org wrote:
On 8/22/13 12:46 PM, Nico Williams wrote:
The parent might be multi-threaded, leading to the risk that a thread
in the parent and the child will obtain the same PRNG outputs until
the parent thread that fork()ed
FYI, in a few weeks I'll have some time to actually implement and
submit patches. I'll attempt to identify useful points for automatic
self-initialization (any hints as to commonly used first calls, not
counting the callback setters, would be welcomed). I'll also have to
spend sometime with the
On Thu, Aug 22, 2013 at 1:00 AM, Patrick Pelletier
c...@funwithsoftware.org wrote:
On 8/21/13 8:55 AM, Nico Williams wrote:
OpenSSL should use pthread_atfork() and mix in more /dev/urandom into
its pool in the child-side of the fork(), Only a child-side handler
is needed, FYI, unless there's
On Thu, Aug 22, 2013 at 2:46 PM, Nico Williams n...@cryptonector.com wrote:
Use of fork() presents many problems, not the least of which is a
performance problem in multi-threaded processes with very large heaps
and high page dirtying rates, such as Java programs. [...]
Also, obviously, web
On Wed, Aug 21, 2013 at 2:19 AM, Patrick Pelletier
c...@funwithsoftware.org wrote:
An easy way to work around this, if you don't mind linking against pthreads,
is to do this at the start of your application, after initializing OpenSSL:
typedef void (*voidfunc) (void);
if
On Wed, Aug 21, 2013 at 5:41 AM, Ben Laurie b...@links.org wrote:
Something needs to be done, but won't this re-introduce the problem of
/dev/random starvation, leading to more use of /dev/urandom (on platforms
where this is a problem)?
Mixing in the time seems like a safer solution that
On Sat, Aug 17, 2013 at 8:49 PM, Scott Doty scott+open...@sonic.net wrote:
That's actually a handy reference, for in looking at Curve25519, I came
across...
http://cr.yp.to/ecdh/patents.html
That's half the point, yes. It'd be all of the point if Curve25519
didn't also rock perf-wise.
On Thu, Aug 15, 2013 at 11:51:05PM -0700, Patrick Pelletier wrote:
Oh. Is there any reason not to blow that away, or at least build-time
select which to use?
I'm in agreement with you; I just don't think you're going to get
the OpenSSL folks on board. They'll probably say something like we
On Fri, Aug 16, 2013 at 02:44:23PM +, Viktor Dukhovni wrote:
On Fri, Aug 16, 2013 at 07:17:22AM -0700, Thomas J. Hruska wrote:
I think a lot of the init logic heralds from the original SSLeay
days. There seems to be intent that initialization is supposed to
happen in main() in the
If only we could agree to use DJB's Curve25519...
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager
Hi, I'm sorry if this has all been discussed extensively before. A
brief search for DLL hell in the archives turns up disappointingly
(and surprisingly) little. I do see a thread with messages from my
erstwhile colleagues at Sun/Oracle, so I know it's been discussed,
e.g., here:
On Thu, Aug 15, 2013 at 10:58 PM, Patrick Pelletier
c...@funwithsoftware.org wrote:
On 8/15/13 10:24 AM, Nico Williams wrote:
. Recent developments, like Android's failure to properly initialize
OpenSSL's PRNG make me think it's time to table (in the British sense)
the issue once more.
Can
28 matches
Mail list logo
