Notices by Hypolite Petovan (hypolite@friendica.mrpetovan.com), page 52

Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Thursday, 21-Apr-2022 20:27:30 EDT Hypolite Petovan

Look, I’m not telling you what to do, I’m just saying everyone should decide for themselves what they want to make up their mind about.

In conversation Thursday, 21-Apr-2022 20:27:30 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Thursday, 21-Apr-2022 13:05:30 EDT Hypolite Petovan

I solved today's Redactle (#15) in 165 guesses with an accuracy of 52.73%. I had the "also know as" term at the 61st try and it took me 100 more tries to find the original term.

Played at www.redactle.com/

In conversation Thursday, 21-Apr-2022 13:05:30 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Thursday, 21-Apr-2022 11:51:52 EDT Hypolite Petovan

From Geoguessr, Khuvsgul Lake in Mongolia:
www.google.com/maps/@50.503004…

In conversation Thursday, 21-Apr-2022 11:51:52 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Thursday, 21-Apr-2022 08:20:04 EDT Hypolite Petovan

♲ @AstroKatie@twitter.com: When you protect your attention by blocking antagonistic strangers someone will always leap to tell you you're creating an echo chamber but if your exploration of the universe of ideas is hindered by troll-blocking your problems will not be solved by listening to them instead

In conversation Thursday, 21-Apr-2022 08:20:04 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Wednesday, 20-Apr-2022 20:50:01 EDT Hypolite Petovan

♲ @smacmccreanor@twitter.com: Choreo by Birds, ft. me and Malia Baker 👌

https://video.twimg.com/ext_tw_video/1516284980011278336/pu/vid/796x720/YGBvzlB5Fu8rxebu.mp4?tag=12

In conversation Wednesday, 20-Apr-2022 20:50:01 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Wednesday, 20-Apr-2022 12:59:25 EDT Hypolite Petovan

I'm hooked and I solved today's Redactle (#14) in 306 guesses with an accuracy of 51.63%. Played at www.redactle.com/

In conversation Wednesday, 20-Apr-2022 12:59:25 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Wednesday, 20-Apr-2022 10:40:04 EDT Hypolite Petovan

"Another check that should’ve saved Java is the check described in step 5 of the verification algorithm on Wikipedia"

Brutal, savage, rekt.

♲ @tqbf@twitter.com: Welp. It’s the crypto bug of the year. Mark it down for April. Java 15-18 ECDSA doesn’t sanity check that the random x coordinate and signature proof are nonzero; a (0,0) signature validates any message. Breaks JWT, SAML, &c. neilmadden.blog/2022/04/19/psy… https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/
In conversation Wednesday, 20-Apr-2022 10:40:04 EDT from friendica.mrpetovan.com permalink
Attachments
1. Invalid filename.
  
  CVE-2022-21449: Psychic Signatures in Java
  
  By Neil Madden from Neil Madden
  The long-running BBC sci-fi show Doctor Who has a recurring plot device where the Doctor manages to get out of trouble by showing an identity card which is actually completely blank. Of course, this being Doctor Who, the card is really made out of a special “psychic paper“, which causes the person looking at it to see whatever the Doctor wants them to see: a security pass, a warrant, or whatever.
  “Looks legit to me. Hic!“
  It turns out that some recent releases of Java were vulnerable to a similar kind of trick, in the implementation of widely-used ECDSA signatures. If you are running one of the vulnerable versions then an attacker can easily forge some types of SSL certificates and handshakes (allowing interception and modification of communications), signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages. All using the digital equivalent of a blank piece of paper.
  
  It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys*) use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs.
  
  If you have deployed Java 15, Java 16, Java 17, or Java 18 in production then you should stop what you are doing and immediately update to install the fixes in the April 2022 Critical Patch Update.
  
  Update: the official announcement from Oracle also lists older versions of Java, including 7, 8 and 11. Although I’m not aware of the bug impacting those older implementations they did fix a similar bug in the (non-EC) DSA implementation at the same time, so it’s possible older versions are also impacted. There are also other security vulnerabilities reported in the same CPU, so (as always) it is worth upgrading even if you are running an older Java version. The OpenJDK advisory on the other hand lists only versions 15, 17, and 18 as affected by this specific issue (CVE-2022-21449).
  
  Oracle have given this a CVSS score of 7.5, assigning no impact to Confidentiality or Availability. Internally, we at ForgeRock graded this a perfect 10.0 due to the wide range of impacts on different functionality in an access management context. ForgeRock customers can read our advisory about this issue for further guidance.
  
  Background: ECDSA signatures
  
  ECDSA stands for the Elliptic Curve Digital Signature Algorithm, and it is a widely used standard for signing all kinds of digital documents. Compared to the older RSA standard, elliptic curve keys and signatures tend to be much smaller for equivalent security, resulting in them being widely used in cases where size is at a premium. For example, the WebAuthn standard for two-factor authentication allows device manufacturers to choose from a wide range of signature algorithms, but in practice almost all of the devices manufactured to date support ECDSA signatures only (a notable exception being Windows Hello, which uses RSA signatures; presumably for compatibility with older TPM hardware).
  
  Without getting too much into the technical details, an ECDSA signature consists of two values, called r and s. To verify an ECDSA signature, the verifier checks an equation involving r, s, the signer’s public key, and a hash of the message. If the two sides of the equation are equal then the signature is valid, otherwise it is rejected.
  
  One side of the equation is r and the other side is multiplied by r and a value derived from s. So it would obviously be a really bad thing if r and s were both 0, because then you’d be checking that 0 = 0 ⨉ [a bunch of stuff], which will be true regardless of the value of [a bunch of stuff]! And that bunch of stuff is the important bits like the message and the public key. This is why the very first check in the ECDSA verification algorithm is to ensure that r and s are both >= 1.
  
  Guess which check Java forgot?
  
  That’s right. Java’s implementation of ECDSA signature verification didn’t check if r or s were zero, so you could produce a signature value in which they are both 0 (appropriately encoded) and Java would accept it as a valid signature for any message and for any public key. The digital equivalent of a blank ID card.
  
  Here’s an interactive jshell session showing the vulnerable implementation accepting a completely blank signature as valid for an arbitrary message and public key:
  
  | Welcome to JShell -- Version 17.0.1 | For an introduction type: /help intro jshell> import java.security.* jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair() keys ==> java.security.KeyPair@626b2d4a jshell> var blankSignature = new byte[64] blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 } jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format") sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized> jshell> sig.initVerify(keys.getPublic()) jshell> sig.update("Hello, World".getBytes()) jshell> sig.verify(blankSignature) $8 ==> true // Oops, that shouldn't have verified...
  
  Note that the “InP1363Format” qualifier just makes it easier to demonstrate the bug. Signatures in ASN.1 DER format can be exploited in the same way, you just have to do a bit more fiddling with the encoding first, but note that JWTs and other formats do use the raw IEEE P1363 format.
  
  A few technical details
  
  If you go and look at the fine details of ECDSA on wikipedia, you’ll see that the right hand side of the equation is not multiplied by s but rather by its multiplicative inverse: s^-1. If you know a little maths, you may be thinking “won’t calculating this inverse result in a division by zero?” But in elliptic curve cryptography, this inverse is being calculated modulo a large number, n, and for the curves typically used in ECDSA, n is a prime number so we can use the Little Theorem of Fermat (vandalizer of margins) to calculate the modular inverse:
  
  xⁿ = x¹ = x (mod n)
  x^(n-1) = x⁰ = 1 (mod n)
  x^(n-2) = x^-1 (mod n)
  
  This is very efficient, and it’s exactly what Java does. However, it is only valid for when x is not zero, as zero doesn’t have a multiplicative inverse. When x is zero then 0^(n-2) = 0: garbage in, garbage out.
  
  The fact that arithmetic is carried out modulo n is also why you need to check that r and s are both < n too, because n = 0 (mod n) so setting r or s to n would have the same effect as setting them to 0.
  
  Another check that should’ve saved Java is the check described in step 5 of the verification algorithm on Wikipedia: checking that a point calculated from r and s is not the “point at infinity”. If r and s are both zero, then the resulting point will in fact be the point at infinity and so this check will fail. But again, Java failed to perform this check.
  
  Why did you just find this now?
  
  You may be wondering why this is just coming to light now, when Java has had ECDSA support for a long time. Has it always been vulnerable?
  
  No. This is a relatively recent bug introduced by a rewrite of the EC code from native C++ code to Java, which happened in the Java 15 release. Although I’m sure that this rewrite has benefits in terms of memory safety and maintainability, it appears that experienced cryptographic engineers have not been involved in the implementation. The original C++ implementation is not vulnerable to these bugs, but the rewrite was. Neither implementation appears to have very good test coverage, and even the most cursory reading of the ECDSA spec would surely suggest testing that invalid r and s values are rejected. I am not at all confident that other bugs aren’t lurking in this code.
  
  What should we do about it?
  
  First of all, if you are using Java 15 or later then please go and update to the latest version to get the fix for this issue.
  
  In general, cryptographic code is very tricky to implement correctly and public key signature algorithms are some of the trickiest. ECDSA is itself one of the most fragile algorithms, where even a tiny amount of bias in one random value can allow complete recovery of your private key. On the other hand, we now have excellent resources like Project Wycheproof that provide test cases for known vulnerabilities. After I found this bug I updated a local copy of Wycheproof to run against Java 17 – it found this issue immediately. Hopefully the JDK team will adopt the Wycheproof test suite themselves to avoid any similar bugs slipping through the net in future.
  
  If you are designing a protocol or application that you think needs to use digital signatures, consider if you really do – would a simpler mechanism work instead? Simple MAC algorithms like HMAC are incredibly hard to mess up compared to signature schemes. If you really need a signature then consider using a modern algorithm like EdDSA that avoids some of the pitfalls of ECDSA.
  
  Timeline
  
  11 Nov 2021 – Issue found and disclosed to OpenJDK vulnerability report email address.
  
  11 Nov 2021 – Determined JDK change that introduced the bug in Java 15.
  
  12 Nov 2021 – Initial acknowledgement from Oracle.
  
  18 Nov 2021 – Oracle confirms the bug and indicates it will be patched in a future Critical Patch Update (CPU). It is assigned tracking ID S1559193.
  
  18 Nov 2021 – ForgeRock issues a security advisory informing our customers not to deploy affected versions of Java into production.
  
  14 Jan 2022 – Ask Oracle for status update. Told that the fix is targeting the April 2022 CPU, scheduled for 19th April.
  
  25 Mar 2022 – Confirm again with Oracle that the fix will be in April CPU. Inform them that ForgeRock will proceed to full disclosure if the bug is not fixed by then.
  
  19 Apr 2022 – Fix released by Oracle in April CPU.
  
  19 Apr 2022 – Article published.
  
  * Yubico is one of the few WebAuthn manufacturers that support the more secure EdDSA standard in addition to ECDSA. EdDSA signatures are less prone to the type of bug described here.
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Tuesday, 19-Apr-2022 13:41:52 EDT Hypolite Petovan

I solved today's Redactle (#13) in 84 guesses with an accuracy of 55.95%. Played at www.redactle.com/

In conversation Tuesday, 19-Apr-2022 13:41:52 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Tuesday, 19-Apr-2022 09:15:01 EDT Hypolite Petovan
- Hypolite Petovan
- Anarkingu Gidora
Exactly! Yesterday I also read “One Piece is the Evangelion of Homestuck” and I know it’s sarcastic but I’m not sure exactly why!

In conversation Tuesday, 19-Apr-2022 09:15:01 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Tuesday, 19-Apr-2022 09:03:21 EDT Hypolite Petovan

I love stumbling on social media posts stating that “X is the Y of Z” when I only have a limited knowledge of X, Y and Z.

In conversation Tuesday, 19-Apr-2022 09:03:21 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Tuesday, 19-Apr-2022 07:59:48 EDT Hypolite Petovan
- Isaac Kuo
I understand cats feel from outer space, but I can assure you they're not!

In conversation Tuesday, 19-Apr-2022 07:59:48 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Monday, 18-Apr-2022 21:45:46 EDT Hypolite Petovan

If extraterrestrial aliens found out about us, I fully believe they would treat us as we treat dogs, and like our dogs, we would not be aware about the dynamic.

In conversation Monday, 18-Apr-2022 21:45:46 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Monday, 18-Apr-2022 06:35:07 EDT Hypolite Petovan
- Hypolite Petovan
- Jonathan Lamothe
It's a good question, right now there's no technical report feature. Offending accounts/servers have to be manually reported to the node admin.

In conversation Monday, 18-Apr-2022 06:35:07 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Sunday, 17-Apr-2022 22:21:48 EDT Hypolite Petovan
Remember the safest rules of engagement on social media:
- Mute/Block/Report
- Move on
Replying or Quoting fuels the behavior that upset you in the first place, they are a double-edge sword you may not want to systematically wield.
In conversation Sunday, 17-Apr-2022 22:21:48 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Sunday, 17-Apr-2022 15:49:47 EDT Hypolite Petovan
- Brad Koehn ☑️
Unfortunately with conservatives screaming murder about alleged censorship on social media, it is still cruelly current.

In conversation Sunday, 17-Apr-2022 15:49:47 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Sunday, 17-Apr-2022 13:45:07 EDT Hypolite Petovan

♲ @ndrew_lawrence@twitter.com: @UrbanAchievr Conservative: I have been censored for my conservative views

Me: Holy shit! You were censored for wanting lower taxes?

Con: LOL no...no not those views

Me: So....deregulation?

Con: Haha no not those views either

Me: Which views, exactly?

Con: Oh, you know the ones

In conversation Sunday, 17-Apr-2022 13:45:07 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Saturday, 16-Apr-2022 20:40:29 EDT Hypolite Petovan

So, I hope there's a high turnover among the people claiming "If your ideas can't win in an open debate, then the problem is with your ideas, not with free expression" because it would be sad to keep claiming it in the face of overwhelmingly contradicting evidence.

In conversation Saturday, 16-Apr-2022 20:40:29 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Friday, 15-Apr-2022 21:11:37 EDT Hypolite Petovan
- **joe
I see your point, but also the state isn't going anywhere anytime soon. So barring a world revolution the best we can do is taking the state at its own word and enforce strong public services. This has been partly subverted through public-private partnerships and arbitrary limits on government spending but it is a closer goal than yours.

In conversation Friday, 15-Apr-2022 21:11:37 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Friday, 15-Apr-2022 18:06:09 EDT Hypolite Petovan
- **joe
How do you make a power grid that is not centralized and yet handles everything smoothly? You need some sort of regulation because the production doesn't perfectly matches the needs. You keep speaking about "them" and "Big Energy" but you've never defined who they are. Decentralization is a nice idea, but it's wasteful and overall less efficient, and while it makes sense for some applications like social networking that isn't critical for some people survival, I do not believe it should be welcome in any public utility like electricity, water, steam/natural gas or sewage networks.

In conversation Friday, 15-Apr-2022 18:06:09 EDT from friendica.mrpetovan.com permalink
Hypolite Petovan (hypolite@friendica.mrpetovan.com)'s status on Friday, 15-Apr-2022 17:58:33 EDT Hypolite Petovan
- **joe
But that's what I mean, to be efficient solar panels and wind turbines need to be deployed at larger scales than what any given house may need. Same for nuclear power, it has a low carbon footprint, a massive and controllable throughput, but it doesn't make sense for any community smaller than a large metropolis.

In conversation Friday, 15-Apr-2022 17:58:33 EDT from friendica.mrpetovan.com permalink

After
Before

Public

Notices by Hypolite Petovan (hypolite@friendica.mrpetovan.com), page 52