similar to: X448 Key Exchange

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

Hi all, Back in September 2018, I started a thread about implementing the X448 key exchange (see https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-September/037183.html). In February 2020, RFC 8731 (formally specifying X448 in SSH) has been finalized: https://www.ietf.org/rfc/rfc8731.txt. I thought I'd start this conversation up again to see if the interest level has

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

See attached: (1) patch against 7.9p1, tested with openssl 1.1.0j and openssl 1.1.1a on linux/i386; passes regression test and connects to unpatched sshd without problems; I hacked a bit regress/unittests/kex, and benchmarked do_kex_with_key("curve25519-sha256 at libssh.org", KEY_ED25519, 256); Before: 0.3295s per call After: 0.2183s per call That is, 50% speedup; assuming

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 -> >>

Hey all, So I do some development based on openssh and I'm trying to think of some new projects that might extend the functionality, feature set, user workflow, performance, etc of ssh. So open ended question: Do any of you have a wish list of things you'd like to see in ssh? Mostly I'm just curious to see what the larger community is thinking of rather than being driven

> 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

>> 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 -> SSL_CTX?) used for the certificate signing request and the signed certificate. The csr

I referred to the fact that there is no value for 4096-bit groups at all. For higher strengths than 128 bits one should probably not use non-EC crypto at all, as the document suggests. On Fri, Feb 15, 2019 at 9:19 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:45, Yegor Ievlev <koops1997 at gmail.com> wrote: > > That doesn't seem to be

On Sat, 26 May 2018, Christian Weisgerber wrote: > On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > > > The defaults for HostKeyAlgorithms option are: [...] > > Why does OpenSSH prefer older and less secure > > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > I asked Markus and Damien about this in the past but honestly

<!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>

there are more implications to changing key algorithms than KEX algorithms. If a change is made to the specification, then it might invalidate all the keys that are out there, this isn't the case with any other negotiated algorithm, On Sun, 27 May 2018, Yegor Ievlev wrote: > I don't think we should wait for a RFC in order to use stronger > crypto. We already prefer Curve25519 for

Hi, I'm doing some test with a pkcs11 token that can only sign short messages. When connecting to one server, that reports pkalg rsa-sha2-512 blen 151, it fails to sign the pubkey because it is 83 bytes long. (sshd: OpenSSH_7.3p1) A older server that reports pkalg ssh-rsa blen 151, works perfectly as the pubkey signature required is only 35 bytes long. (sshd: OpenSSH_6.7p1) I am not sure