search for: secp256r1

...lient ] then revealed (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : Extension: supported_groups (len=10) ??? Type: supported_groups (10) ??? Length: 10 ??? Supported Groups List Length: 8 ??? Supported Groups (4 groups) ??????? Supported Group: x25519 (0x001d) ??????? Supported Group: secp256r1 (0x0017) ??????? Supported Group: secp521r1 (0x0019) ??????? Supported Group: secp384r1 (0x0018) Apparently [ brainpool ] would apparently not fit into any of those groups. Perhaps a bug in OpenSSL 1.1.0h thus.

...Hello) : >> >> Extension: supported_groups (len=10) >> ??? Type: supported_groups (10) >> ??? Length: 10 >> ??? Supported Groups List Length: 8 >> ??? Supported Groups (4 groups) >> ??????? Supported Group: x25519 (0x001d) >> ??????? Supported Group: secp256r1 (0x0017) >> ??????? Supported Group: secp521r1 (0x0019) >> ??????? Supported Group: secp384r1 (0x0018) >> >> Apparently [ brainpool ] would apparently not fit into any of those >> groups. Perhaps a bug in OpenSSL 1.1.0h thus. >> >> > Turned out not being...

Hello I get the following error when using our Let's Encrypt ssl certificate for webRTC calls : [Jun 2 14:29:28] == DTLS ECDH initialized (secp256r1), faster PFS enabled [Jun 2 14:29:28] ERROR[27360][C-00000ae5]: res_rtp_asterisk.c:1441 ast_rtp_dtls_set_configuration: Specified certificate file '/etc/letsencrypt/live/ws.mydomain.tld/privkey.pem' for RTP instance '0x7f920c538a78' could not be used [Jun 2 14:29:28] ERROR[2736...

...------------> [May 10 10:45:24] --- (13 headers 129 lines) --- [May 10 10:45:24] Using INVITE request as basis request - 3g51uvbnnioje6riokqu [May 10 10:45:24] Found peer 'testacc7700476' for 'testacc7700476' from 99.99.255.55:47732 [May 10 10:45:24]   == DTLS ECDH initialized (secp256r1), faster PFS enabled [May 10 10:45:24]   == DTLS ECDH initialized (secp256r1), faster PFS enabled [May 10 10:45:24]   == Using SIP VIDEO TOS bits 136 [May 10 10:45:24]   == Using SIP VIDEO CoS mark 4 [May 10 10:45:24]   == Using SIP RTP TOS bits 184 [May 10 10:45:24]   == Using SIP RTP CoS mark 5 [...

...ayer: Handshake Protocol: Client Hello) : > > Extension: supported_groups (len=10) > ??? Type: supported_groups (10) > ??? Length: 10 > ??? Supported Groups List Length: 8 > ??? Supported Groups (4 groups) > ??????? Supported Group: x25519 (0x001d) > ??????? Supported Group: secp256r1 (0x0017) > ??????? Supported Group: secp521r1 (0x0019) > ??????? Supported Group: secp384r1 (0x0018) > > Apparently [ brainpool ] would apparently not fit into any of those > groups. Perhaps a bug in OpenSSL 1.1.0h thus. > > Turned out not being a bug in OpenSSL after all. Fro...

...gt; Extension: supported_groups (len=10) >>> ??? Type: supported_groups (10) >>> ??? Length: 10 >>> ??? Supported Groups List Length: 8 >>> ??? Supported Groups (4 groups) >>> ??????? Supported Group: x25519 (0x001d) >>> ??????? Supported Group: secp256r1 (0x0017) >>> ??????? Supported Group: secp521r1 (0x0019) >>> ??????? Supported Group: secp384r1 (0x0018) >>> >>> Apparently [ brainpool ] would apparently not fit into any of those >>> groups. Perhaps a bug in OpenSSL 1.1.0h thus. >>> >>&g...

Hey i have an interesting topic to discuss here. The main goal here is to be able to make a video call between two WebRTC endpoints registered on asterisk 13 it is a feature that definitely asterisk 13 should support . the problems that i faced with this is the following and i hope i could get an advise here. asterisk 13 vanilla version has some issues marking the video packets this complain

..._groups (len=10) >>>> ??? Type: supported_groups (10) >>>> ??? Length: 10 >>>> ??? Supported Groups List Length: 8 >>>> ??? Supported Groups (4 groups) >>>> ??????? Supported Group: x25519 (0x001d) >>>> ??????? Supported Group: secp256r1 (0x0017) >>>> ??????? Supported Group: secp521r1 (0x0019) >>>> ??????? Supported Group: secp384r1 (0x0018) >>>> >>>> Apparently [ brainpool ] would apparently not fit into any of those >>>> groups. Perhaps a bug in OpenSSL 1.1.0h thus. &gt...

...h using. OpenSSL supports X25519, and that is half the battle. Is there a way to change the curve selection in Dovecot? On 2018-12-19 01:49, Tributh via dovecot wrote: > Do you really plan to do this? > RFC 8446 section 9.1: > A TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 > > I think your idea could be not future proved. > > Beside that, how many mail-clients will remain usable with this cipher > selection? > > Torsten -------------- next part -------------- An HTML attachment was...

...;: Found [Oct 7 23:58:40] == Parsing '/etc/asterisk/sipTemplates.conf': Found [Oct 7 23:58:40] == Parsing '/etc/asterisk/users.conf': Found [Oct 7 23:58:40] == Using SIP TOS bits 96 [Oct 7 23:58:40] == Using SIP CoS mark 3 [Oct 7 23:58:40] == TLS/SSL ECDH initialized (secp256r1), faster PFS cipher-suites enabled [Oct 7 23:58:40] == TLS/SSL certificate ok --> no more output on CLI. Asterisk has gone completely ! Another 'sip reload' gives : sip5*CLI> sip reload [Oct 8 00:01:10] Previous SIP reload not yet done sip5*CLI> sip reload sip5*CLI> O...

I am interested in configuring Dovecot's TLS so as to retain forward secrecy, but eliminate all of NIST's elliptic curves. Besides being subject to side channel attacks [1], in some quarters there is a general distrust of NIST's curves and any of their other cryptographic primitives after the Dual EC DRBG debacle. >From what I can tell, the following will prevent the use of

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 30 July 2018 at 21:00 ѽ҉ᶬḳ℠ < <a href="mailto:vtol@gmx.net">vtol@gmx.net</a>> wrote: </div> <div> <br>

On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Lack of time on the Open Source projects is understandable, and not uncommon. > > However, PKCS11 has been in the codebase practically forever - the ECC > patches that I saw did not alter the API or such. It is especially > non-invasive when digital signature is concerned. > > Considering how long those patches have