search for: curdle

...nger apply. > I've been wanting to hassle Markus and Damien about this again, > once I run into them in person, but that opportunity hasn't presented > itself yet. Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html Christian is right about our reasoning for the other choices. -d

...e Markus and Damien about this again, > >> once I run into them in person, but that opportunity hasn't presented > >> itself yet. > > > > Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at > > https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html > > > > Christian is right about our reasoning for the other choices. > > > > -d > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.or...

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2515 Bug ID: 2515 Summary: Implement diffie-hellman-group{14,15,16)-sha256 Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P3 Component: ssh Assignee: dtucker at

...8: https://tools.ietf.org/html/rfc7748). Furthermore, it is included in the new TLS 1.3 specification (RFC8846: https://tools.ietf.org/html/rfc8446). A few questions: 1. What has been OpenSSH's involvement in this related IETF draft, if any?: https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-08.html 2. Has there been any (even informal) plans for including X448? 3. Has anyone begun an implementation yet? I've got some experience with OpenSSH development, so I wouldn't mind writing a first draft of a patch. I just don't want to duplicate effo...

https://bugzilla.mindrot.org/show_bug.cgi?id=2680 Bug ID: 2680 Summary: Regression in server-sig-algs offer in 7.4p1 (Deprecation of SHA1 is not being enforced) Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

...ClearAllForwardings to be optionally overridden when using ssh -W. bz#2577 * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per draft-sgtatham-secsh-iutf8-00. * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA signatures in certificates; * ssh(1): Add an Include directive for ssh_config(5) files. * ssh(1): Permit UTF-8 characters in pre-authentication banners sent from the server. bz#2058 Bugfixes --------...

The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure

On 09/24/2017 12:21 AM, Mark D. Baushke wrote: > I suggest you upgrade to a more recent edition of the OpenSSH software. > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released > very soon. This problem is in v7.5 and v7.6. See dh.c:436. > OpenSSH 6.6 was first released on October 6, 2014. I brought up v6.6 to give an example that older clients wouldn't be

...ClearAllForwardings to be optionally overridden when using ssh -W. bz#2577 * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per draft-sgtatham-secsh-iutf8-00. * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA signatures in certificates; * ssh(1): Add an Include directive for ssh_config(5) files. * ssh(1): Permit UTF-8 characters in pre-authentication banners sent from the server. bz#2058 Bugfixes --------...

On 25 September 2017 at 02:32, Mark D. Baushke <mdb at juniper.net> wrote: > [+CC Loganaden Velvindron <logan at hackers.mu>] primary author of > the RFC 4419 refresh draft. https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ ? Tangent: has any consideration been given to increasing the maximum allowed beyond 8192 bits (which is below the current NIST recommendation for 256 bits of security)? Last time I looked OpenSSL supported 10k bits out of the box so it probably wouldn't be hard to support...

Hello, I was wondering about the case below. I tried to find any information in C standard, but I found nothing. In this case, variable "i" is uninitialized, but it is the _same_ value passed as an argument, so only of "a" or "b" should be printed. What I found is that with -O2: LLVM (trunk) prints both "a" and "b" GCC (4.2) prints both

...g in the form that i outline here. the purpose of 2) is to protect the community and the foundation from creating exactly these kinds of purple nasties. [a purple nasty is what you get if you mix a blue-coloured aniseed liqueur with a red-coloured cream liqueur. the cream happily curdles and also goes purple. sadly, purple nasties are also undrinkable: i did try because i didn't want an entire glass of 40% cocktail to go to waste without knowing what it tasted like. pfh.] 3) that acceptance of contributions are considered for STRATEGIC as WELL as technical grounds...