On 29/12/2018 22:33, Richard Levitte wrote:
In message <20181229.170846.804158981742723988.levi...@openssl.org> on Sat, 29 Dec
2018 17:08:46 +0100 (CET), Richard Levitte said:
In message <38b97114-0c66-40ed-f631-58aa20940...@gmx.de> on Sat, 29 Dec 2018 14:19:47 +0100,
"C.Wehrmeyer" said:
On Mon, Dec 31, 2018 at 02:11:56PM +, Matt Caswell wrote:
>
> Well, you have vocally complained about the state of the documentation. You
> have
> the benefit of being a new OpenSSL user. You know what things were confusing
> or
> unclear in the documentation. More experienced OpenSSL
3 - 6 months
Happy New Year..;)
> On 1 Jan 2019, at 02:43, Richard Levitte wrote:
>
> I'll go ahead and ask, how long do you think such a back door would
> stay unnoticed, let alone survive? I'm considering the fact that we
> have a lot of people looking at our code, just judging from the
I'll go ahead and ask, how long do you think such a back door would
stay unnoticed, let alone survive? I'm considering the fact that we
have a lot of people looking at our code, just judging from the issues
and pull requests raised on github.
I can't say that I have an actual answer, but it's a
Matt et al
'been reviewed and approved by two current OpenSSL committers (one of whom must
be on the OpenSSL Management Committee).’
Due to the recent legislative changes here in Australia around the T.O.L.A.
Act, can a change be made to the OpenSSL policy so that the 2 reviewers, don’t
On 31/12/2018 11:36, C.Wehrmeyer wrote:
> On 31.12.18 10:12, Richard Levitte wrote:
>> Yes, it's true, new features are going in. And it's true that it's
>> often more exciting to add new features than to do the janitorial
>> work.
>
> You realised what I have left unspoken thus far, which is
kudos, matt milosevic. you have not complicated matters but rightly
reminded us of the need for civility and the benefits that accrue from
such an approach in opposition to merely railing while offering little
in the way of a path towards problem resolution. also, appreciation to
richard levitte
On 31.12.18 10:12, Richard Levitte wrote:
Yes, it's true, new features are going in. And it's true that it's
often more exciting to add new features than to do the janitorial
work.
You realised what I have left unspoken thus far, which is this almost
obsession-like preference of OSS coders
In message <4d287beb-f79b-5fb8-9a6f-8a612c175...@gmx.de> on Sun, 30 Dec 2018
16:45:27 +0100, "C.Wehrmeyer" said:
> On 30.12.18 00:04, Matt Milosevic wrote:
> > I do not want to complicate matters further, but there needs to be one
> > thing clear here: this library is mainly developed and
On 30.12.18 00:04, Matt Milosevic wrote:
> I do not want to complicate matters further, but there needs to be one
> thing clear here: this library is mainly developed and maintained by
> /volunteers/.
For some reason you seem to think this excuses something. I don't.
Fact is: there are a lot of
On 29/12/2018 22:08, C.Wehrmeyer wrote:
How am I supposed to get more adept when the documentation is a literal
mess?
Let me reverse that: What is the *point* of getting more adept with the
API when I feel more and more disgusted by learning how it's working
internally?
Welcome to The
On 12/29/2018 7:53 AM, Jakob Bohm via openssl-users wrote:
> Well, these two latter arrays look like a stray copy of the HMAC
> constants "ipad" and "opad", which (while looking like ASCII), are
> defined as exact hex constants even on a non-ASCII machine, such
> as PDP-11 or an IBM mainframe.
I do not want to complicate matters further, but there needs to be one
thing clear here: this library is mainly developed and maintained by
/volunteers/. They're putting in time and effort to improve the state of
the crypto ecosystem, and they seem to be doing a damn good job at it, as
even you,
On 29.12.18 21:32, Viktor Dukhovni wrote:
> I said it, neither because it can't be done, nor because it is
> incompatible with session caching, or has anything to do with
> ephemeral key agreement (which works just fine even with
> session resumption), but simply because it is easier for a
>
When we're starting to stoop to this level, I think it's time to step
away from the screen and take a few deep breaths... or maybe even go
away and take a nap, go for a walk, or something else. Then, perhaps
come back in a better mood.
Cheers,
Richard ( am off to sleep, it's getting late over
In message <20181229.170846.804158981742723988.levi...@openssl.org> on Sat, 29
Dec 2018 17:08:46 +0100 (CET), Richard Levitte said:
> In message <38b97114-0c66-40ed-f631-58aa20940...@gmx.de> on Sat, 29 Dec 2018
> 14:19:47 +0100, "C.Wehrmeyer" said:
>
...
> > What's wrong with that, you ask?
> I didn't bother looking up what freeing entails - it's obvious to
> anyone at this point that OpenSSL is a severe victim of feature creep,
> that its memory allocation scheme is a mess, and long story short: I
> will NOT free a perfectly fine object just because of incompetent
You really have no idea how to code. You look like one of those junior
engineers that think they know it all.
I won't be replying again, so don't need to get your hopes up.
Na(o) sábado, 29 de dez de 2018, 17:19, C.Wehrmeyer
escreveu:
> On 29.12.18 16:53, Jakob Bohm via openssl-users wrote:
>
> On Dec 29, 2018, at 8:19 AM, C.Wehrmeyer wrote:
>
> OK, so I've been reading the mails before going to sleep and spent some time
> thinking and researching about this, and I've come to a conclusion: OpenSSL
> is a goddamn mess, SSL_clear() is pretty much superfluous, and as such
> shouldn't
On 29/12/2018 17:18, C.Wehrmeyer wrote:
On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct
portable code which derives obviously and
> straightforwardly from the specification, you'd write arrays of a
> different length from the original, the first 48 bytes of which would
> only be
On 29.12.18 16:53, Jakob Bohm via openssl-users wrote:
> The session caching in the SSL and TLS protocols is to skip the
> expensive key exchange when reconnecting within a few seconds,
> as is extremely common with web browsers opening up to 8 parallel
> connections to each server.
My outburst
On 29/12/2018 13:19, C.Wehrmeyer wrote:
...
Your corrections, improvements and enhancements would be very welcome as
pull requests at https://github.com/openssl/openssl - thank you for your
contributions.
And don't give me any "trust us, we're experienced programmers"
bullshit. I've
In message <38b97114-0c66-40ed-f631-58aa20940...@gmx.de> on Sat, 29 Dec 2018
14:19:47 +0100, "C.Wehrmeyer" said:
> I've written highly scalable libraries in the past before, and one
> thing you always want to do there is to trim fat.
Sure, but:
> Now add to that the fact that OpenSSL has been
On 29/12/2018 14:19, C.Wehrmeyer wrote:
I don't have access to the actual testing environments until Wednesday
next year, so I've had to create a private account.
> Which version of OpenSSL is this? (I don't remember if you said this
> already).
I'm not entirely sure, but I *think* it's
I don't have access to the actual testing environments until Wednesday
next year, so I've had to create a private account.
> Which version of OpenSSL is this? (I don't remember if you said this
> already).
I'm not entirely sure, but I *think* it's 1.1.0.
> On Dec 28, 2018, at 6:17 AM, Christian wrote:
>
> BIO_set_fd with 4|1 #Socket 4, BIO_CLOSE
> SSL_set_accept_state
> SSL_accept
> SSL_accept failed, SSL_get_error: 1 #SSL_ERROR_SSL
> 140059505588032:error:1408F119:SSL routines:ssl3_get_record:decryption failed
> or
On 28/12/2018 10:22, Christian wrote:
> Thank you for the suggestions thus far. I've been working on a simple SSL
> client/server system in the last couple days. Unfortunately the SSL
> documentation is a right mess, so I don't know what is allowed and what is
> not,
> which leads to some
I should also add that printing the error stack doesn't yield much info
other than "you dun goof'd":
===
First connection, client closes connection as excepted.
===
BIO_set_fd with 4|1 #Socket 4, BIO_CLOSE
SSL_set_accept_state
SSL_accept
Thank you for the suggestions thus far. I've been working on a simple
SSL client/server system in the last couple days. Unfortunately the SSL
documentation is a right mess, so I don't know what is allowed and what
is not, which leads to some problems that I don't know exactly how to
tackle on.
On 25/12/2018 20:07, Michel wrote:
> Thanks Matt for the reminder about the use of PSK in TLS 1.3.
> This leads me to this other question :
> Can someone please clarify what is the future of SRP starting with TLS 1.3 ?
SRP is not currently supported in OpenSSL with TLSv1.3. AFAIK there is no
Thanks Matt for the reminder about the use of PSK in TLS 1.3.
This leads me to this other question :
Can someone please clarify what is the future of SRP starting with TLS 1.3 ?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 24/12/2018 19:52, Viktor Dukhovni wrote:
>> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users
>> wrote:
>>
>> Pre-shared keys (PSK) don't require certs, maybe that meets the need. A
>> thing to know about PSK is that each side is fully trusted, and if one side
>> gets the key
> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users
> wrote:
>
> Pre-shared keys (PSK) don't require certs, maybe that meets the need. A
> thing to know about PSK is that each side is fully trusted, and if one side
> gets the key stolen, then the thief can pretend to be either side.
>While certificate-less TLS is in theory possible with RFC7250 bare public
> keys
Pre-shared keys (PSK) don't require certs, maybe that meets the need. A thing
to know about PSK is that each side is fully trusted, and if one side gets the
key stolen, then the thief can pretend to be
On Mon, Dec 24, 2018 at 04:29:49PM +, Matt Caswell wrote:
> How about using PSKs? That way you completely avoid the need for a
> certificate.
> Authentication is implied since both peers must have access to the PSK for the
> connection to succeed. ECDHE can be combined with the PSK to create
On 24/12/2018 11:51, Christian wrote:
> Hello, people. I'm a beginner with OpenSSL and with cryptography in general,
> and
> have been wondering how to best implement an upcoming system.
>
> I apologise in advance for any grammar or orthography mistakes, as English
> isn't
> my native
On Mon, Dec 24, 2018 at 04:25:54PM +0100, Christian wrote:
> > Your research has led you astray. The ECDHE-RSA-AES128-GCM-SHA25
> > ciphersuiteo *is* RSA authenticated and offers forward secrecy,
>
> Then how would I load my static RSA keys into my SSL_CTX? Simply by
> using
Your research has led you astray. The ECDHE-RSA-AES128-GCM-SHA25
ciphersuiteo *is* RSA authenticated and offers forward secrecy,
Then how would I load my static RSA keys into my SSL_CTX? Simply by
using SSL_CTX_use_PrivateKey_file on client and server? As far as I
understand the mechanism
On Mon, Dec 24, 2018 at 12:51:17PM +0100, Christian wrote:
> This sounds like a typical RSA scenario, however I also want to have
> forward security, which requires me to use something with temporary keys
> only - I'm having ECDHE in mind for that, ECDHE-RSA-AES128-GCM-SHA256 in
> particular.
Hello, people. I'm a beginner with OpenSSL and with cryptography in
general, and have been wondering how to best implement an upcoming system.
I apologise in advance for any grammar or orthography mistakes, as
English isn't my native language.
We have a local network with a databse in which
40 matches
Mail list logo
