search for: brainpoolp512r1

On 31.07.2018 03:32, ????? wrote: >> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >> >> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >> >> And thus t1 would not work anyway. However, having tested r1 the result >> was just the same. >> >> A tcpdump during the openssl test [ s_server | s_client ] then revealed >> (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : >> >> Ext...

...host:5555 >> > Uhum, I see now. What a strange thing (bug?) openssl is doing. Thank you > for valuable time/effort having debug this. Seems I have to start the CA > all over... Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] And thus t1 would not work anyway. However, having tested r1 the result was just the same. A tcpdump during the openssl test [ s_server | s_client ] then revealed (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : Extension: supported_groups (len=10) ??? Type: supported_groups (10) ???...

> >>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >>> >>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >>> >>> And thus t1 would not work anyway. However, having tested r1 the result >>> was just the same. >>> >>> A tcpdump during the openssl test [ s_server | s_client ] then revealed >>> (TLSv1.2 Record Layer: Handshake Protocol: Client Hello)...

On 31.07.2018 09:30, ????? wrote: >>>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >>>> >>>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >>>> >>>> And thus t1 would not work anyway. However, having tested r1 the result >>>> was just the same. >>>> >>>> A tcpdump during the openssl test [ s_server | s_client ] then revealed >>>> (TLSv1.2 Record Layer: Handshake...

> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: > > [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] > > And thus t1 would not work anyway. However, having tested r1 the result > was just the same. > > A tcpdump during the openssl test [ s_server | s_client ] then revealed > (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : > > Extension: supported_groups (len=10...

...inpool curves are defined in RFC 5639. ? Please find attached a patch file that adds support for Brainpool Elliptic Curves in OpenSSH. Currently, setting the bit size to 256, 384 or 521 selects one of the matching NIST curves - specification of named curves not supported. I added 512, which selects brainpoolP512r1 (canonically). Furthermore, you can specify the nick name of an Elliptic Curve using the -b switch of ssh-keygen. Supported nick names are: nistp256, nistp384, nistp521 and the Brainpool ones: brainpoolP256r1, brainpoolP256t1 brainpoolP384r1, brainpoolP384t1 brainpoolP512r1, brainpoolP512t1 Wo...

...v> brainpoolP320t1: RFC 5639 curve over a 320 bit prime field </div> <div> brainpoolP384r1: RFC 5639 curve over a 384 bit prime field </div> <div> brainpoolP384t1: RFC 5639 curve over a 384 bit prime field </div> <div> brainpoolP512r1: RFC 5639 curve over a 512 bit prime field </div> <div> brainpoolP512t1: RFC 5639 curve over a 512 bit prime field </div> </blockquote> <div> <br> </div> <div> try </div> <div> <br> </div>...

...poolP256t1: RFC 5639 curve over a 256 bit prime field ? brainpoolP320r1: RFC 5639 curve over a 320 bit prime field ? brainpoolP320t1: RFC 5639 curve over a 320 bit prime field ? brainpoolP384r1: RFC 5639 curve over a 384 bit prime field ? brainpoolP384t1: RFC 5639 curve over a 384 bit prime field ? brainpoolP512r1: RFC 5639 curve over a 512 bit prime field ? brainpoolP512t1: RFC 5639 curve over a 512 bit prime field

> On 30 July 2018 at 20:37 ????? <vtol at gmx.net> wrote: > > > > >>>>>>> facing [ no shared cipher ] error with EC private keys. > >>>>>> the client connecting to your instance has to support ecdsa > >>>>>> > >>>>>> > >>>>> It does - Thunderbird 60.0b10 (64-bit) >

...r/vmail/sieve/global/learn-spam.sieve imapsieve_mailbox1_causes = COPY imapsieve_mailbox1_name = Spam imapsieve_mailbox2_before = file:/var/vmail/sieve/global/learn-ham.sieve imapsieve_mailbox2_causes = COPY imapsieve_mailbox2_from = Spam imapsieve_mailbox2_name = * mail_crypt_curve = brainpoolP512r1 mail_crypt_require_encrypted_user_key = # hidden, use -P to show it mail_crypt_save_version = 2 quota = maildir:User quota quota_exceeded_message = Benutzer %u hat das Speichervolumen ?berschritten. / User %u has exhausted allowed storage space. sieve = file:/var/vmail/sieve/%d/%n/scripts...

In the past 24 hours multiple persons have contacted me regarding the use of elliptic curve cryptography in tinc 1.1 in light of the suspicion that the NSA might have weakened algorithms and/or elliptic curves published by NIST. The new protocol in tinc 1.1 (SPTPS) uses ECDH and ECDSA to do session key exchange and authentication, in such a way that it has the perfect forward secrecy (PFS)

In the past 24 hours multiple persons have contacted me regarding the use of elliptic curve cryptography in tinc 1.1 in light of the suspicion that the NSA might have weakened algorithms and/or elliptic curves published by NIST. The new protocol in tinc 1.1 (SPTPS) uses ECDH and ECDSA to do session key exchange and authentication, in such a way that it has the perfect forward secrecy (PFS)