[HN Gopher] PuTTY vulnerability vuln-p521-bias
___________________________________________________________________
PuTTY vulnerability vuln-p521-bias
Author : aardvark179
Score : 200 points
Date : 2024-04-15 19:24 UTC (3 hours ago)
(HTM) web link (www.chiark.greenend.org.uk)
(TXT) w3m dump (www.chiark.greenend.org.uk)
| chasil wrote:
| I use P521 for all my server host keys. Do these need to be
| rotated after my users upgrade their PuTTY clients?
| strbean wrote:
| > (The problem is not with how the key was originally
| generated; it doesn't matter whether it came from PuTTYgen or
| somewhere else. What matters is whether it was ever used with
| PuTTY or Pageant.)
|
| Sounds like your server keys are safe.
| germinator wrote:
| This exposed client keys, not server keys. The client keys are
| at risk only in a handful of specific scenarios - e.g., if used
| to connect to rogue or compromised servers, or used for signing
| outside SSH.
|
| This is _not_ exploitable by simply passively watching traffic,
| so even for client keys, if you 're certain that they were used
| in a constrained way, you should be fine. The difficulty is
| knowing that for sure, so it's still prudent to rotate.
| Skrillor wrote:
| No, only NIST P-521 client keys used with PuTTY are affected.
| The server host key signature is computed by the server (most
| likely OpenSSH) which is unaffected.
| axus wrote:
| Good thing everyone uses the defaults and never picks that type
| of key!
| formerly_proven wrote:
| ECDSA strikes again. Bad nonce generation (here: generating a 521
| bit nonce by calculating a 512 bit number and then taking that
| modulo 2^521, which means the top bits of the nonce are always
| zero) leading to private key compromise. Classic.
| JamesCoyne wrote:
| Details in the excellent commit message
| https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c...
| rainsford wrote:
| Yes, although this is the rare ECDSA private key recovery issue
| where deterministic nonce generation was the cause of rather
| than the solution to the problem.
| metadat wrote:
| I wish this announcement included the backstory of how someone
| discovered this vulnerability.
|
| Public keys are enough of a pain in the ass with PuTTY / KiTTY
| that I stick with password auth for my windows SSH'ing needs.
|
| KiTTY even let's you save the passwords so you don't have to type
| it in, a horrible security practice no doubt, but so
| convenient... Perhaps more secure than the putty-gen'd ECDSA P521
| keys? A tad bit ironic.
| chasil wrote:
| Ironically, DJB considers the 521 curve to be the only NIST
| standard that uses reasonable primes.
|
| "To be fair I should mention that there's one standard NIST
| curve using a nice prime, namely 2^521 - 1; but the sheer size
| of this prime makes it much slower than NIST P-256."
|
| http://blog.cr.yp.to/20140323-ecdsa.html
|
| http://safecurves.cr.yp.to/rigid.html
| pclmulqdq wrote:
| The 521 curve is the only one using a Mersenne prime, which
| has significant advantages when you do calculations, but also
| feels less arbitrary.
| kwantam wrote:
| This vulnerability has very little to do with P-521 per se.
| The issue is with ECDSA: _any_ use of ECDSA with biased nonce
| generation, regardless of the elliptic curve it 's
| implemented over, immediately causes secret key leakage.
|
| (Rant: All these years later, we're all still doing penance
| for the fact that Schnorr signatures were patented and so
| everyone used ECDSA instead. It's an absolute garbage fire of
| a signature scheme and should be abandoned yesterday for many
| reasons, e.g., no real proof of security, terrible footguns
| like this.)
| orev wrote:
| You should be using pageant to store the secret ssh keys, and
| you only need to unlock the key on reboot/first use.
| metadat wrote:
| 100% agreed.
|
| For me, the stakes are very low. It's my windows "gaming"
| machine, and has access to a few low-value hosts.
|
| Otherwise I'd invest the time to learn wtf is pageant ;D
| lambdafu wrote:
| If the hosts are under your control, and never connect to
| untrusted hosts, then you are ok. The user authentication
| is encrypted, so the signatures are not visible to a man in
| the middle.
| adw wrote:
| Pageant is `ssh-agent`.
| wkat4242 wrote:
| Or just use a hardware key and enable touch to sign so you
| have to touch it for every action even when it's unlocked
| spacemanspiff01 wrote:
| Windows has a built in ssh-agent included with openssh, no
| need for pagent anymore.
|
| Ssh agent will manage your ssh keys through windows registry
| windows login process.
|
| Also if you use wsl, you can access your ssh keys in wsl from
| the windows ssh-agent via npiperelay
| lambdafu wrote:
| We found it by investigating the security of SSH as part of a
| larger research program focussing on SSH, which also resulted
| in our publication of the Terrapin vulnerability.
|
| This particular bug basically fell into our hands while staring
| at the source code during our investigation of the security of
| SSH client signatures.
| tptacek wrote:
| Assuming I'm reading it right, this is an absolutely classic
| vulnerability, something people who study cryptographic
| vulnerability research would instinctually check for, so what's
| taken so long is probably for anyone to bother evaluating the
| P-521 implementation in PuTTY.
| some_furry wrote:
| Correct. Every time I've seen P-521 in a professional
| setting, it is the _very first_ thing I check for.
| delfinom wrote:
| Windows 10+ now have openssh proper by Microsoft. No need to
| use putty with it's own custom key format among other nonsense.
| WorldMaker wrote:
| Sometimes useful reminder: you may not need PuTTY today. On the
| one side Windows Terminal does a lot of the classic VT* terminal
| emulation that old ConHost did not. On the other side Windows
| ships "real" OpenSSH now as a feature that turns on automatically
| with Windows "Dev Mode". No built in GUI for the SSH agent, but
| at this point if you are familiar with SSH then using a CLI SSH
| agent shouldn't be scary. If you are "upgrading" from PuTTY you
| just need to export your keys to a different format, but that's
| about the only big change.
|
| PuTTY was a great tool for many years and a lot of people have
| good reasons to not want to let it go. As with most software it
| accretes habits and processes built on top of it that are hard to
| leave. But also useful to sometimes remind about the new options
| because you never know who wants to be in the Lucky 10K to learn
| that Windows Terminal now has deeper, "true" terminal emulation
| or that Windows has ssh "built-in".
| chasil wrote:
| I am on a corporate desktop, so I cannot use the Microsoft
| variant of the ssh-agent: C:\Users\luser>ssh-
| agent unable to start ssh-agent service, error :1058
|
| Obviously, getting that changed globally (or even for myself)
| is impossible.
|
| PuTTY has a workaround, allowing PAGENT.EXE to be used in place
| of the forbidden/inaccessible Microsoft agent:
|
| https://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter9...
|
| So PuTTY remains quite relevant because of the mechanisms that
| Microsoft has chosen.
| WorldMaker wrote:
| I'm sorry that you need to work around the inability to run a
| simple Windows service because of some mistakenly bad
| corporate policy trying to micro-manage which Windows
| services are allowed to run. I don't think the long term
| solution should be "shadow IT install an older app just
| because it pretends to be a GUI rather than a Windows
| service", but I'm glad it is working for you in the short
| term.
|
| If you need ammunition to encourage your corporate IT to
| allow you to run the proper ssh-agent service to do your job
| instead of increasing your attack surface by installing
| PuTTY/Pageant, you could collect a list of vulnerabilities
| such as the one posted here (look at the huge count of
| affected versions on just this one!). There should be plenty
| of vulnerability maintenance evidence on the Microsoft-
| shipped version of an open source tool with a lot of eyeballs
| because it is "the standard" for almost all platforms _over_
| the "single developer" tool that took at least a decade off
| from active development (and it shows).
| DEADMINCE wrote:
| > some mistakenly bad corporate policy trying to micro-
| manage which Windows services are allowed to run.
|
| Actually, I'd say that's a _good_ corporate policy.
| blueflow wrote:
| Really helpful. I found challenge in getting a Windows system
| (no admin) into a state where i can use it productively, and
| having a functional ssh-agent was one of the remaining pain
| points.
| naikrovek wrote:
| ALWAYS GOOGLE THE ERROR MESSAGE, with context about what
| you're doing!
|
| I encountered this, too, but the fix is quite simple.
|
| That service is set to "manual" by default, (or maybe
| "disabled") and setting it to "automatic" then starting it
| will get you running.
|
| It is unlikely that this is a corporate lockdown measure.
| smackeyacky wrote:
| There are a few different options in Windows that are all
| measurably superior to PuTTY:
|
| Install WSL2 - you get the Linux SSH of your choice.
|
| As mentioned above, Windows now ships with OpenSSH and windows
| terminal is good.
|
| My favourite, but now probably obsolete solution was to install
| MobaXTerm which shipped with an SSH client. It's still great
| and there is a usable "free" version of it, but WSL2 does
| everything for me now when I'm forced to use windows.
| kelsey98765431 wrote:
| Friendly reminder you can entirely disable elliptic curve
| algorithms in your sshd_config and generate rsa keys larger than
| 4096 bits, 8192 or however large you like work just fine.
|
| I have never trusted EC crypto because of all the magic involved
| with it, a sufficient reason to move from RSA has never been
| presented with compelling evidence as far as I am concerned. I do
| not care that it is faster, i prefer slow and secure to fast and
| complicated. It's a lot easier to explain RSA and why it's secure
| than the mile long justifications on curve crypto. The issue
| doesn't need to be in the algorithm, if the implementation is
| sufficiently difficult that works just as well as an
| intentionally misdesigned algorithm.
| wkat4242 wrote:
| Yeah I never bought into the EC thing much either.
|
| It's supposed to be safer against quantum but it's also a lot
| less proven.
| lambdafu wrote:
| Actually, with currently common key sizes, ECC up to 384 bits
| will fall to QC before RSA with 1024 bits, because fewer bits
| means fewer qubits needed.
|
| The main disadvantage of RSA is the structure of finite
| fields, which allows specialized solutions to factoring
| (number field sieve). We do not know similar structures for
| elliptic curves, so for those we only have general attacks,
| thus allowing shorter key lengths.
| gruez wrote:
| edit: ignore below, I misinterpreted what q meant in this context
| and thought it was the private key.
|
| >The clever trick is to compute a secure hash whose input
| includes the message to be signed and also the private key [...]
|
| > PuTTY's technique worked by making a SHA-512 hash, and then
| reducing it mod q, where q is the order of the group used in the
| DSA system. For integer DSA (for which PuTTY's technique was
| originally developed), q is about 160 bits; for elliptic-curve
| DSA (which came later) it has about the same number of bits as
| the curve modulus, so 256 or 384 or 521 bits for the NIST curves.
|
| I know hindsight is 20/20, but why did PuTTY implement it this
| way to begin with? Given the description in the first paragraph,
| I'd naively implemented it as SHA-512(message
| || private_key)[:number_of_bits_required]
|
| or if I was being paranoid I would have done
| SHA-512(SHA-512(message) ||
| SHA-512(private_key))[:number_of_bits_required]
|
| Moduloing it by q makes no sense unless you're trying to save a
| few cycles.
| chasil wrote:
| It appears that some of this was designed in the late 90s/early
| aughts, when Windows didn't have a cryptographically-secure
| random number generator.
|
| PuTTY carries its own formats from this time.
| gruez wrote:
| You don't need a CSPRNG to do SHA512, which their solution
| already incorporates.
| chasil wrote:
| This is the text from the original article.
|
| "For this reason, since PuTTY was developed on Windows
| before it had any cryptographic random number generator at
| all, PuTTY has always generated its k using a deterministic
| method, avoiding the need for random numbers at all."
| gruez wrote:
| Both my proposed naive method and the PuTTY
| implementation are deterministic. The only difference is
| how the primitives (eg. SHA-512) are combined.
| yorwba wrote:
| The problem is that 521 > 512, not that they used modulo. To
| get a sufficiently large nonce out of the hash, you need to
| think in terms of expanding the number of bits, not reducing
| it.
| gruez wrote:
| Ah okay, after re-reading the message it looks like using the
| SHA-512 result directly (without modulo) would still have the
| issue. I originally thought the problem was moduloing by the
| key, which was approximately 521 bits
|
| > In all of those cases except P521, the bias introduced by
| reducing a 512-bit number mod q is negligible. But in the
| case of P521, where q has 521 bits (i.e. more than 512),
| reducing a 512-bit number mod q has no effect at all - you
| get a value of k whose top 9 bits are always zero.
| tptacek wrote:
| Presumably because 512 of bits (a) seemed "random enough" and
| (b) was the nicest block size that fit comfortably in 521 bits
| of modulus. This is a common mistake.
| Denvercoder9 wrote:
| From TFA it seems more like they already had the SHA512-based
| implementation for DSA (where it was fine), and reused it
| when implementing ECDSA without realizing that it wasn't
| suitable in situations with moduli larger than 512 bits.
| tptacek wrote:
| I'd have to look at the code, but a DSA modulus is much
| larger than a P-521 modulus. Maybe it just happened to line
| up nicely?
| kwantam wrote:
| The nonce is taken modulo the order of the prime-order
| subgroup. For DSA that's generally a 256ish-bit prime
| (e.g.: choose a 1024-bit prime p such that a 256-bit
| prime q divides p-1; then there exists an order-q
| subgroup of Zp).
|
| For P-521, the base field is 2^521 - 1, but the modulus
| used when computing the nonce is not that value, it's the
| _order_ of the P-521 curve. By Hasse 's theorem, that's
| roughly p +- sqrt(p), which is essentially p for such
| large numbers (the cofactor of P-521 is 1, so the order
| of the group is prime).
|
| So: both are 521-bit numbers, but the group order is less
| than 2^521-1. Its hex representation is 0x01fffffffffffff
| ffffffffffffffffffffffffffffffffffffffffffffffffffffa5186
| 8783bf2f966b7fcc0148f709a5d03bb5c9b8899c47aebb6fb71e91386
| 409.
| tptacek wrote:
| Ahh. Thanks! (I don't think about FFDLP much, as you can
| see).
| smarx007 wrote:
| SHA-512(...)[:521] would still produce the same vulnerability,
| there would be 9 unchanging bits (assuming the [:521] would pad
| the 512 bits to 521). Those 9 guessable bits are enough to
| recover the key from 60 signatures, as the post explained in
| detail.
|
| A more interesting question (while we are on the 20/20
| hindsight express) is why the dsa_gen_k() function did not
| include an assert(digest_len <= 512).
| aidenn0 wrote:
| Isn't modulo the same as truncation when dealing with powers of
| two?
| gruez wrote:
| Good point. I misread the OP and thought q was the key, but
| really it just corresponded to the key length (eg. 521 for
| p521)
| lambdafu wrote:
| Caution here. If your modulus is too close to the maximum
| truncated value, there can be a bias in the upper bits, too.
| For example, if you reduce a number between 0 and 15 by the
| modulus 13, the values 0, 1 and 2 will be twice as likely as
| the values 3-12. This means that the highest bit will be 0 in
| 11 out of 16 cases. Even such a small bias might be
| exploitable (for example, sub 1 bit bias up to 160-bit ECDSA
| here: Gao, Wang, Hu, He https://eprint.iacr.org/2024/296.pdf)
| aidenn0 wrote:
| Neither 15 nor 13 are powers of two.
| wbl wrote:
| But 16 is.
| some_furry wrote:
| The interval [0, 15] represent 16 possible values, which
| is a power of 2.
|
| The correct way to get an unbiased distribution from a
| sample of 2^x to a modulo that is not an even power of 2
| is to use rejection sampling.
|
| This is what RFC 6979 says to do
| https://datatracker.ietf.org/doc/html/rfc6979#section-3.2
|
| But you can also see this technique in CSPRNG code; i.e.
| https://github.com/php/php-
| src/blob/d40726670fd2915dcd807673...
| aidenn0 wrote:
| I missed it was [0,15]
|
| This doesn't make 13 a power of two. I'm aware of
| rejection sampling; my point was if you have a N bit
| value X and want M bits, truncating X to M bits and X MOD
| 2*M is the same. Neither solve the problem where M > N,
| which is what TFA is about.
| some_furry wrote:
| > This doesn't make 13 a power of two.
|
| Where did I imply that it is?
|
| > I'm aware of rejection sampling; my point was if you
| have a N bit value X and want M bits, truncating X to M
| bits and X MOD 2*M is the same.
|
| Sure.
|
| > Neither solve the problem where M > N, which is what
| TFA is about.
|
| If you observe my other comments, you'll see I'm well
| aware of what the article is about.
| aidenn0 wrote:
| > Where did I imply that it is?
|
| You used 13 as an example in a response to my comment
| that was:
|
| _Isn 't modulo the same as truncation when dealing with
| powers of two?_
| some_furry wrote:
| > You used 13 as an example
|
| I don't see the number 13 in any of my comments on this
| thread (except this one, or where I quoted you). Perhaps
| you are confusing me with someone else?
| some_furry wrote:
| You'd want something like this: Truncate(
| SHA-512(0x01 || message || private_key) ||
| SHA-512(0x02 || message || private_key), bitsNeeded
| )
|
| Two separate hashes, with domain separation, that produce an
| output of at least n+64 bits (if it is to be reduced mod 2^n -
| k, for some small integer k). In this case, 1024 bits reduced
| mod 2^521-1 is safe.
|
| Even better, though, is to just use RFC 6979 and not implement
| it yourself.
| AtNightWeCode wrote:
| We recommend against ECDSA for internal accounts. I know several
| of our partners use it though. Hard to not be cynical about this
| even though this issue seems mostly harmless.
| AtNightWeCode wrote:
| NSA disagrees...
| tptacek wrote:
| This is one of the all-time cryptography footguns, an absolutely
| perfect example of how systems development intuition fails in
| cryptography engineering.
|
| The problem here is the distinction between an n-bit random
| number and n-bit modulus. In DSA, if you're working with a
| 521-bit modulus, and you need a random k value for it, k needs to
| be random across all 521-bits.
|
| Systems programming intuition tells you that a 512-bit random
| number is, to within mind-boggling tolerances, as unguessable as
| a 521-bit random number. But that's not the point. A 512 bit
| modulus leaves 9 zero bits, which are legible to cryptanalysis as
| bias. In the DSA/ECDSA equation, this reduces through linear
| algebra to the Hidden Number Problem, solvable over some number
| of sample signatures for the private key using CVP.
|
| _Later_
|
| Here you go, from Sean Devlin's Cryptopals Set 8:
|
| https://cryptopals.com/sets/8/challenges/62.txt
| rainsford wrote:
| What's really interesting to me is that there was a known
| solution to the DSA/ECDSA nonce generation problem, RFC 6979,
| which was published 4 years before the vulnerability was
| introduced into PuTTY. And it sounds like the developer knew
| about this RFC at the time but didn't implement it because the
| much earlier version of deterministic nonce generation that
| PuTTY already had seemed similar enough and the differences
| were assessed to not be security critical.
|
| So I think the other lesson here is that deviating from a
| cryptographic right answer is a major footgun unless you
| understand _exactly_ why the recommendation works the way it
| does and _exactly_ what the implications are of you doing it
| differently.
| tptacek wrote:
| I think 6979 is a bit of a red herring here. 6979 is about
| deterministic nonce generation, which is what you do to dodge
| the problem of having an insecure RNG. But the problem here
| isn't that the RNG is secure; it's more fundamentally a
| problem of not understanding what the rules of the nonce are.
|
| But I may be hair-splitting. Like, yeah, they freelanced
| their own _deterministic_ nonce generation. Either way, I
| think this code long predates 6979.
| rainsford wrote:
| I was going based off the commit link posted further down
| the thread (https://git.tartarus.org/?p=simon/putty.git;a=c
| ommitdiff;h=c...). You're right that the PuTTY
| deterministic nonce generating code does appear to
| significantly predate the RFC, but it sounds like the
| developer made a conscious decision when 6979 came out not
| to switch from what PuTTY already had because they looked
| similar enough. The PuTTY release that introduced support
| for elliptic curve cryptography (and introduced this
| vulnerability) was 0.68, which came out in 2017, 4 years
| after the RFC.
|
| You're right that this was not an RNG security problem and
| instead was a problem with not understanding ECDSA nonce
| rules. However the notable fact for me was that the
| developer was apparently aware of the recommended way to
| deterministically generate nonces prior to the
| vulnerability being introduced and made a choice not to
| implement the RFC because what PuTTY was already doing
| seemed close enough, without fully understanding the
| implications of doing so. To put it another way,
| understanding ECDSA nonce rules would have avoided this
| vulnerability, but so too would implementing the RFC
| recommended way even if the developer did not fully
| understand why it was better than the existing
| implementation.
| tptacek wrote:
| Right, the reason I'm splitting hairs is that in my
| intuition, the whole rationale for 6979 is to eliminate
| the possibility of _fully repeated nonces_ , for instance
| because your RNG is "unseeded". You can still end up with
| a biased nonce even if you're using a perfectly seeded
| random bit generator (as you can see here). But yeah I
| think we understand each other.
|
| As you can probably see, I just love this bug class, is
| all.
| kwantam wrote:
| RFC6979 attempts to guarantee that the nonce is unbiased
| (under the assumption that HMAC's output is
| indistinguishable from random). It's definitely
| attempting to give a stronger property than simply
| preventing a repeated nonce.
|
| See step (h) in Section 3.2. The nonce is selected by
| rejection sampling. Thus, under the above assumption
| about HMAC, the result is indistinguishable from
| uniformly random in the [1, q-1] range.
| rainsford wrote:
| > As you can probably see, I just love this bug class, is
| all.
|
| I agree! DSA nonce issues are a great class of
| cryptographic bug in that they're sort of weirdly
| unexpected failure properties when you first hear about
| it.
| akerl_ wrote:
| The article addresses this: they wrote this code path in
| 2001. RFC 6979 was authored in 2013.
| rainsford wrote:
| But elliptic curve support and this vulnerability weren't
| introduced until 2017, and the commit log (https://git.tart
| arus.org/?p=simon/putty.git;a=commitdiff;h=c...) makes it
| clear the developer was aware of the RFC but chose not to
| upgrade the 2001 code. Doing so prior to the elliptic curve
| support being added would have completely avoided this
| vulnerability.
| garaetjjte wrote:
| I don't think anybody consciously looked at 9 zero bits and
| thought _this is fine_ , but it rather looks like unfortunate
| effect of plugging old code into new algorithms without proper
| verification.
| rainsford wrote:
| You could be right. If you look at the old code, dsa_gen_k(),
| that was removed during the commit (https://git.tartarus.org/
| ?p=simon/putty.git;a=commitdiff;h=c...), it does basically no
| bounds checking, presumably because at the time it was
| written it was assumed that all modulus values would be many
| fewer bits than the size of a SHA-512 output.
|
| So it would have been pretty easy to just reuse the function
| for a modulus value that was too big without encountering any
| errors. And the old code was written 15+ years before it was
| used for P-521, so it's entirely possible the developer
| forgot the limitations of the dsa_gen_k() function. So maybe
| there's another lesson here about bounds checking inputs and
| outputs even if they don't apply to anything you're currently
| doing.
| londons_explore wrote:
| So this signing method requires a 521 bit random number, and this
| flaw caused the top 9 bits of that number to be zero instead, and
| somehow after 60 signatures this leaks the private key?
|
| Anyone care to explain how exactly? How it it any different to
| the top 9 bits being zero by chance (which happens in 1 out of
| ~500 attempts anyway)
| lambdafu wrote:
| For the attack all 60 signatures need a nonce that is special
| in this way. If for example only one out of the 60 is short,
| the attack fails in the lattice reduction step. The reason is
| that in the attack, all 60 short nonces "collude" to make up a
| very special short vector in the lattice, which is much shorter
| than usual because it is short in all 60 dimensions, not just
| one out of 500 dimensions. The approximate shortest vector is
| then obtainable in polynomial time, and this happens to contain
| the secret key by construction. As an analogy: Imagine you had
| a treasure map with 60 steps "go left, go right, go up, go
| down, go down again" etc. If only one out of 60 instructions
| where correct, you wouldn't know where the treasure is. All of
| the instructions need to be correct to get there.
| jwilk wrote:
| Sure, it happens by chance, but the attacker doesn't know when
| it happens.
| wkat4242 wrote:
| Cool, I never use keys generated by putty, so I'm good. I only
| use keys generated by hardware tokens like yubikeys and openpgp
| smartcards.
| Bootvis wrote:
| From the article:
|
| > (The problem is not with how the key was originally
| generated; it doesn't matter whether it came from PuTTYgen or
| somewhere else. What matters is whether it was ever used with
| PuTTY or Pageant.)
| garaetjjte wrote:
| Smartcards do signing operations on the card itself, so it
| doesn't apply in this case.
| ZekeSulastin wrote:
| Edit: beat to it, whoops! Never underestimate the Internet's
| drive to post easy corrections >.>
|
| ----
|
| Unfortunately, about that:
|
| "(The problem is not with how the key was originally generated;
| it doesn't matter whether it came from PuTTYgen or somewhere
| else. What matters is whether it was ever _used_ with PuTTY or
| Pageant.)"
| gorgoiler wrote:
| A complete aside, but I just realised that putty is named after
| the old fashioned adhesive clay used to cement window panes into
| the frames of windows.
|
| PuTTY... Windows... gosh I feel dumb. I've used putty for almost
| _25 years_ but didn't put two and two together until I just
| remembered how the pheasants in my garden would peck out the
| window putty to get at the ladybirds hibernating underneath.
| MaxBarraclough wrote:
| I don't have a substantive comment to offer, but good on Simon
| Tatham for the clear and forthcoming write-up. No damage-control
| lawyerly BS, no 'ego', just the facts about the issue.
|
| It's reassuring to see a solid disclosure after a security issue,
| and we too often see half-truths and deceptive downplaying, e.g.
| LastPass.
| Kikawala wrote:
| If you haven't already, this is probably a good time to switch to
| EdDSA keys. EdDSA signatures don't require RNG nor modular math
| unlike ECSDA signatures.
| eyegor wrote:
| Despite being fairly old, many systems still don't support
| eddsa. As an example, the reference browser/ca spec doesn't
| allow it: https://cabforum.org/working-groups/server/baseline-
| requirem.... Last I tried, even let's encrypt won't grant an
| ed25519 cert despite it being in tls 1.3 (2018?).
| throw0101c wrote:
| > _Last I tried, even let 's encrypt won't grant an ed25519
| cert despite it being in tls 1.3 (2018?)._
|
| Talk to the CA/Browser Forum. SS6.1.5 Keys Sizes:
|
| > _For RSA key pairs the CA SHALL:_
|
| > _* Ensure that the modulus size, when encoded, is at least
| 2048 bits, and;_
|
| > _* Ensure that the modulus size, in bits, is evenly
| divisible by 8._
|
| > _For ECDSA key pairs, the CA SHALL:_
|
| > _* Ensure that the key represents a valid point on the NIST
| P-256, NIST P-384 or NIST P-521 elliptic curve._
|
| > _No other algorithms or key sizes are permitted._
|
| * https://cabforum.org/uploads/CA-Browser-Forum-TLS-
| BRs-v2.0.2...
|
| * https://cabforum.org/working-groups/server/baseline-
| requirem...
|
| Ed25519 (and Ed448) was only 'recently' approved by NIST FIPS
| 186-5 in February 2023.
| kwantam wrote:
| EdDSA signatures are specified to use deterministic nonce
| generation, so you're correct that they do not require
| randomness. But they certainly do require modular arithmetic in
| order to implement the elliptic curve operations!
___________________________________________________________________
(page generated 2024-04-15 23:00 UTC)