search for: koops1997

That's not a very good source, since it's only available to one person. On Fri, May 25, 2018 at 7:12 AM, Peter Moody <mindrot at hda3.com> wrote: > On Thu, May 24, 2018 at 9:09 PM, Yegor Ievlev <koops1997 at gmail.com> wrote: >> How can I revoke one SSH certificate without having to replace the >> root certificate and all certificates signed by it? > > there is no chaining of ssh certificates. > >> Regarding the second statement, do you have sources? > > yes. my d...

e.g. can we make it throw warnings etc. rsa-sha2-256 and rsa-sha2-512 are fine, they use PSS. On Sun, Jan 20, 2019 at 1:55 AM Yegor Ievlev <koops1997 at gmail.com> wrote: > > Also can we do anything with ssh-rsa? It uses both SHA-1 and > deprecated PKCS#1 padding. If it's used to sign certificates, there's > no additional protection of SHA-2 hashing before SHA-1 signature, it > just signs the raw certificate. > >...

...revoke one SSH certificate without having to replace the root certificate and all certificates signed by it? Regarding the second statement, do you have sources? On Fri, May 25, 2018 at 6:58 AM, Peter Moody <mindrot at hda3.com> wrote: > On Thu, May 24, 2018 at 8:36 PM, Yegor Ievlev <koops1997 at gmail.com> wrote: > >> SSH certificates provide no >> way to revoke compromised certificates, > > this isn't true > >> and SSH certificates haven't seen significant adoption, > > this also isn't true. > > enterprises love ssh certificates.

I don't think there is any point to generate so many moduli. Actually, 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I'm not nearly knowledgeable enough in crypto to fully understand your > > answer, but I will try. I wonder why moduli are not automatically > > generated the first time sshd is started though. That would make much > > more sense than shipping...

...hat doesn't seem to be the case. See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf (5.6.1 Comparable Algorithm Strengths) On Fri, Feb 15, 2019 at 8:28 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I don't think there is any point to generate so many moduli. Actually, > > 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. > > NIST SP 800-57 Part 1, on which the current group size selection code > is based, puts a 4k group at a l...

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

I'm not sure if collision resistance is required for DH key derivation, but generally, SHA-1 is on its way out. If it's possible (if there's not a very large percentage of servers that do not support anything newer), it should be disabled.

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

...sha1/sha256 chosen? Are they chosen randomly by developers or are they chosen for security properties? If they are random, why not use moduli from RFC 7919 instead, like Mozilla recommends? On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997 at gmail.com> writes: > > > Can we disable diffie-hellman-group14-sha1 too? > > It is possible to disable the diffie-hellman-group14-sha1 key exchange, > but I personally recommend you just put it at the end of the list, so it > is not normally used for the key exhcange unle...

...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 the case. See > > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf > > (5.6.1 Comparable Algorithm Strengths) > > For DH, the "Comparable strengths" table lists L=3072 for 128 bits...

...not automatically generated the first time sshd is started though. That would make much more sense than shipping a default moduli file but also asking everyone to replace it with their own. On Fri, Feb 15, 2019 at 5:50 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997 at gmail.com> writes: > > > Also, how are default moduli shipped with OpenSSH for use in > > diffie-hellman-group-exchange-sha1/sha256 chosen? > > You should never use a moduli file shipped by any distribution. Ever. > > If you are using OpenSSH, then look at the modul...

Also, Jerry Solinas, the person listed as an author of the curves, also is the author of DUAL_EC_DRBG. On Tue, May 29, 2018 at 3:43 AM, Damien Miller <djm at mindrot.org> wrote: > On Tue, 29 May 2018, Damien Miller wrote: > >> We're aware of those arguments but don't find them convincing enough to >> switch early. > > (but we will be switching to ssh-ed25519

Can we disable diffie-hellman-group14-sha1 too? On Thu, Feb 14, 2019 at 10:23 PM Mark D. Baushke <mdb at juniper.net> wrote: > > Hi John, > > The short answer is YES. > > Jon DeVree <nuxi at vault24.org> writes: > > > I ask because the removal of diffie-hellman-group-exchange-sha1 happened > > accidently in 7.8 due to a mistake in a change to

...Curve25519 for key exchange without waiting > for it. So why wait for a RFC in this case? > > On Sun, May 27, 2018 at 5:09 AM, Damien Miller <djm at mindrot.org> wrote: > > 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 M...

I suggest deprecating proprietary SSH certificates and move to X.509 certificates. The reasons why I suggest this change are: X.509 certificates are the standard on the web, SSH certificates provide no way to revoke compromised certificates, and SSH certificates haven't seen significant adoption, It's also a bad idea to roll your own crypto, and own certificate format seems like an example

Please tell me in technical details how current revocation support works, or give links. Then I will be able to give an answer. On Fri, May 25, 2018 at 7:16 AM, Damien Miller <djm at mindrot.org> wrote: > > > On Fri, 25 May 2018, Yegor Ievlev wrote: > >> Can you implement revocation support? > > What do you want that the existing revocation support lacks?

Zero matches in both. https://linux.die.net/man/5/sshd_config https://linux.die.net/man/5/ssh_config On Fri, May 25, 2018 at 7:48 AM, Damien Miller <djm at mindrot.org> wrote: > On Fri, 25 May 2018, Yegor Ievlev wrote: > >> Please tell me in technical details how current revocation support >> works, or give links. Then I will be able to give an answer. > > Please

Can you implement revocation support? On Fri, May 25, 2018 at 6:55 AM, Damien Miller <djm at mindrot.org> wrote: > No way, sorry. > > The OpenSSH certificate format was significantly motivated by X.509's > syntactic and semantic complexity, and the consequent attack surface in > the sensitive pre-authentication paths of our code. We're very happy to > be able to

Compressing data before encryption may be dangerous, for example CRIME, BREACH and VORACLE. Can compression be disabled by default in OpenSSH, only being enabled if user requests it? Another scenario when SSH compression may be bad is use of commands like tar cz | ssh root at remote "tar xz", which seem pretty common. If SSH compression is enabled, data will be (wastefully) compressed

Well, SSHFP is supposed to only be used on DNSSEC-enabled domains. On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > It would make more sense to treat SSHFP records in the same way as > > known_hosts > > I disagree with that - known_hosts is nominally a client-local configuration. > > I think it's a very bad