similar to: [PATCH] use ecdh/X25519 from openssl when possible (openssl-1.1.0+)

On some cpu's optimized chacha implementation in openssl (1.1.0+) is notably faster (and on others it is just faster) than generic C implementation in openssh. Sadly, openssl's chacha20-poly1305 (EVP_chacha20_poly1305) uses different scheme (with padding/etc - see rfc8439) and it looks it is not possible to use in openssh. OpenSSL 1.1.1+ also exports "raw" poly1305 primitive,

On Fri, 2019-07-12 at 15:54 +1000, Damien Miller wrote: > On Thu, 17 Jan 2019, Yuriy M. Kaminskiy wrote: > > > On some cpu's optimized chacha implementation in openssl (1.1.0+) > > is > > notably faster (and on others it is just faster) than generic C > > implementation in openssh. > > > > Sadly, openssl's chacha20-poly1305

Hi, OpenSSH 6.9 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is

My opinion is that security by RFC is not security, it's mommy medicine. Standards have had a terrible time keeping up with security realities. NITS's curves leak side channel information all over the place. I don't have details on what implementations are set to calculate the NIST curves in constant time, and that's not an easy feat to do anyway so I don't want to depend

Hi all, I'm interested in having X448 protocol available as an option, as it gives a larger security margin over X25519. For anyone unfamiliar, it is an Diffie-Hellman elliptic curve key exchange using Curve448 (defined in RFC7748: https://tools.ietf.org/html/rfc7748). Furthermore, it is included in the new TLS 1.3 specification (RFC8846: https://tools.ietf.org/html/rfc8446).

On Tue, 23 Jun 2015, Jakub Jelen wrote: > > On 05/29/2015 09:12 AM, Damien Miller wrote: > > Hi, > > > > OpenSSH 6.9 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains > > some substantial new features and a number of bugfixes. > Tested basic configuration on Fedora 22. With

On 09/13/2018 08:18 PM, Damien Miller wrote: > We have any plans to add more crypto options to OpenSSH without a strong > justification, and I don't see one for X448-SHA512 ATM. What I like about it is that it offers ~224 bit security level, whereas X25519 offers ~128 bits (according to RFC7748). Hence, pairing X448 with AES256 would provide a full chain of security in the ~224 bit

Hello, I don't know who will read this message, but I found this thread: https://www.mail-archive.com/search?l=dovecot at dovecot.org&q=subject:%22Dovecot+2.3.0+TLS%22&o=newest And I'm expected the same issue, I will try to explain to you (english is not my native language, sorry) Since Buster update, so Dovecot update too, I'm not able to connect to my mail server from my

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

>>>> I did some local testing and it seems that you are using a curve >>>> that is not acceptable for openssl as a server key. >>>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>>> -port 5555 >>>> using cert generated with brainpool. Everything works if I use >>>> prime256v1 or secp521r1. This is a

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

>>>>>> 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) >>>> >>>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >>>> >>>> It seems there is

I have several samba servers on Debian 10 all using : samba 2:4.9.5+dfsg-5+deb10u1 amd64 I use tls cafile, tls certfile and tls keyfile with certificates from Sectigo (https://cert-manager.com) And when checking my connexion from the samba server, or from outside, I've got "unable to verify the first certificate" even if tls_cafile is provided in smb.conf. What is wrong

>>>> 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) >> >> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >> >> It seems there is a difference between the private key (rsa vs. ecc -> >>

A non-text attachment was scrubbed... Name: 0001-Remove-unused-since-ssh1-protocol-removal-crc32.-ch.patch Type: text/x-patch Size: 20097 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190206/ca9d8d10/attachment-0001.bin>

> On 05/07/2020 19:43 Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > > > > On 04/07/2020 21:12 la.jolie at paquerette <la.jolie at paquerette.org> wrote: > > > > > > Hello, > > > > I'm trying to configure roundcube / dovecot to work with keycloak. > > I activated xoauth2 oauthbearer in dovecot. > > But a problem

Hello Aki, I have this problem just with 2.3.8, my self-compiled 2.3.3 works fine. I have previously tried to update from 2.3.3 to higher versions (possibly 2.3.5 or so), but always had this error, which is why I am always back to 2.3.3. Configuration is exactly the same. Here my output from "doveconf -n": # 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf# Pigeonhole version 0.5.8

# HG changeset patch # User David Hicks <david at hicks.id.au> # Date 1373085976 -36000 # Sat Jul 06 14:46:16 2013 +1000 # Node ID ccd83f38e4b484ae18f69ea08631eefcaf6a4a4e # Parent 1fbac590b9d4dc05d81247515477bfe6192c262c login-common: Add support for ECDH/ECDHE cipher suites ECDH temporary key parameter selection must be performed during OpenSSL context initialisation before ECDH and

Hello, I recently tried to build my system with libressl instead of openssl. In dovecot one issue that popped up was that libressl doesn't have the ECDH auto functions from openssl 1.0.2 beta versions. However as the #ifdef's in dovecot's code check for the openssl version and libressl's version numbers are higher the compilation fails there. Attached is a patch that will change

Hi, My CentOS has upgrade the openssl to 1.1.1a, and I thought my tinc(1.0.35) installed by yum will use the new openssl, but it looks not the fact. So is tinc(1.0.35) support openssl 1.1.1a? If so, how can I make it running in this version of openssl?