Thanks for the hint. The problem is fixed.
Server was setting:
if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
//
}
The call succeeds.
But the old TLS 1.2 code was setting:
int nid = NID_X9_62_prime256v1;
EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
Forgot to add that when you do provide the engine impl in the
EVP_DigestSignInit() invocation, the app fails because it tries to “outsource”
the digesting of the data to the engine as well:
$ ./t2a
Using YubiHSM device...
Signature padding is RSA-PSS padding
Enter PKCS#11 token PIN for Yub
This bug prevents normal working of EVP_DigestSignInit() and subsequent calls
when pkcs11 engine is involved.
Scenario: hashing and signing data, when signing is done on a token that
supports only internal padding (aka it performs RSA-PSS padding on-board,
rather than letting software such a
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:
> I am attaching a pcap where I set the supported list to contain X25519.
> The client extension contains X25519. However, the server still responds
> with keyshare extension secp256r1 in a hello retry request.
>
Are you calling SSL_CTX_set1_group
I am attaching a pcap where I set the supported list to contain X25519.
The client extension contains X25519. However, the server still responds
with keyshare extension secp256r1 in a hello retry request.
This is the case for all the 5 TLS 1.3 ciphers. Is there another setting
for the server to
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:
> if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>//error
> }
>
If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.
>
On 3 October 2017 at 20:45, Hanno Böck wrote:
> On Tue, 3 Oct 2017 17:36:03 +
> "Salz, Rich via openssl-dev" wrote:
>
> So I heard chatter about this, but not much details. Which I find
> unfortunate and a bit disturbing. (I'm aware of a single case with
> bluetooth HW, but this sounds like
if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
//error
}
The client and server both use SSL_CTX_set1_groups-list to set the
supported group list. Right now, the server always
has P-256 in the supported groups extension.
When the the groups list is c
On 10/04/2017 04:30 AM, Matt Caswell wrote:
>
> Looks like we should have an exception for this case (with a suitable
> comment explaining why). Will you create a PR?
>
Yes, I was planning to. I was just taking some time to ponder whether
it's worth burning an option bit on, to allow an opt-out (
On Wed, Oct 04, 2017, Matt Caswell wrote:
>
> As Tomas said - that ship has sailed. In my mind that change was a
> mistake. It could have been done in a non-breaking way by introducing a
> new header format at that time.
>
As regards a new header format. In the case of some of the structures we
It's not specific to devops. Here, a quick history lesson:
https://english.stackexchange.com/questions/20356/origin-of-i-can-haz
Cheers
Richard
Ted Marynicz skrev: (4 oktober 2017 10:53:35 CEST)
>Haz?
>
>Is that some kind of devops-speak I am not (yet) aware of?
>
>Ted
>(a grand-father)
>
>On
On 03/10/17 18:51, Robin H. Johnson wrote:
> On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote:
>> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
>>>
1.2. This also opens the path to stronger key derivation (PBKDF2)
2. During decryption, if no header block is present, a
On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote:
> Hi all,
>
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elli
Haz?
Is that some kind of devops-speak I am not (yet) aware of?
Ted
(a grand-father)
On 3 October 2017 at 18:36, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:
> Some people have asked why TLS 1.3 isn’t available yet. This might help;
> it’s a draft of a posting for my company’s
[...]
I think we probably should have an option to not write out the header at all
- but not to "increase security by obscurity". Rather it would be about
having the ability to write out a "raw" encrypted file that could be
consumed by some other tool.
[...]
+1
I will probably come back on this
15 matches
Mail list logo
