There was a confusing name change, and it doesn’t help that ecdsa/ed25519 has two names, but the number 25519 is specific to this fixed version. Funnily if you quote search nsa and ec25519, this thread is the only result besides one ycom thread (which also is in context of them being safe).

ec25519 is not a typical name for it used in any software afaik, only in writing.

Edit: Historically ecdsa used to refer to the backdoored one. Since it has fallen so much out of use, ecdsa now means ed25519 since it’s usually imcorrecly called ecdsa and also changed to ed25519. It is of course better to specify 25519.

Speaking of which

and intentionally put vulnerabilities into Ec25519

25519 is the fixed one. It is also not backdoored. Please fix that aswell. It is only Dual_EC_DRBG that is affected, not RSA nor ECDSA/ED25519

NSA has long since broken RSA

This is clearly referring to the algorithm. You don’t “break” a company.

There is also little reason to bring up the RSA company at all, it is for all intents completely irrelevant.

Please just edit your root message to talk about the EC (Dual_EC_DRBG) that is not really in use anywhere but at least real and something security people know of.

If you say the nsa has broken rsa, you are making a lot of sysadmins sweat for no reason.

You linked the article I was talking about.

There are two, different, unrelated things:

RSA, Rivest–Shamir–Adleman, an asymmetric encryption, that comes in sizes like rsa2048 and rsa4096. It is now, having largely been replaced by ecdsa, which is using elliptic curves, a different kind of mathematics. The main benefit of EC is smaller key sizes.
If you have old ssh keys, they are likely id_rsa. New ones are likely id_ecdsa.

The NSA tried to backdoor elliptic curves, long after rsa the encryption was already around (rsa encryption dates back to the 70s). This presumably nsa-backdoored EC implementation is quite famous, and what your article is talking about on the technical side. This EC has been largely abandoned. An ssh key named id_ecdsa or id_ed25519 will be using a known secure EC using different safe seed values.

Now, RSA encryption and EC encryption are two separate categories, an asymmetric encryption algorithm is either RSA or EC (or something else), but never both.

Enter stage left the company “RSA”, RSA Security LLC.
This is a company originally founded to market rsa encryption, hence the name. It has long been owned by another company within which it now deals with many different encryption algorithms and related tech.
It does not own the rsa algorithm, and it of course has no influence over it. The algorithm is set in stone and has been for decades. If you try to change it you are making something new with a different name.

This company was naturally dealing with the hot new encryption tech of 2014, called EC cryptography. Which, as you may recall, is mutually exclusive to being the rsa algorithm.

RSA Security LLC was apparenlty influenced by the nsa to adopt their broken EC cryptography. This of course makes the company, their products, etc., all suspect.

Now stay with me here. The company RSA Security LLC, which is suspect, is not related to the algorithm called RSA. If the company is suspect, this does not call the RSA algorithm into question, which has been subject of cryptographic analysis for decades and predates RSA Security LLC by a number of years.

The suspect thing is a special EC crptographic implementation, which excludes the rsa algorithm being involved.

Now let’s read the article:

[…] Dual_EC_DRBG, was ratified by the National Institute of Standards and Technology (NIST) in 2007 and is attracting a lot of attention for having a potential backdoor. This is the algorithm into which the NSA allegedly inserted a backdoor and then paid RSA to use.

An EC algorithm. Meaning not RSA.
“paid RSA”. Since this is definitely not RSA encryption, it must be RSA Security LLC.
“paid RSA”. You cannot pay an algorithm, only a company. Thus, this is RSA Security LLC.

My dude, rsa is fine. This article is talking about a company called rsa, not rsa encryption.
I have never heard of doubt about rsa’s security, given enough size. The main issue with raa is that it needs to be thousands of bits in size due to not being very efficient. And of course it is not post quantum.

GTT (gpu swap) is handled by the gpu driver, so only nvidia can see if they can add it to their closed source drivers. radv is the amd vulkan driver.

This means continued security patches until at least end of 2027, so at the earliest these will be out of support in 2028.

Realistically this will be much longer into the future, as the LTS window of multiple LTS releases is likely to be extended more.
I’d be surprised if these go out of support before 2032

Molly supports unified push

Notification logging is usually done by some other part of android as far as I know. GMS is the typical way to deliver notifications and is a far more serious privacy concern, since it also directly passes googles servers and is not encrypted. However as others mentioned, signal does not send contents there, message notifications with the message contents stay on device.

This is about a history of notifications locally on the phone.
This is implemented outside of gms at least on my rom, and in the past I have also installed a separate app to do the same.
If you log your notifications … that log can leak your notifications.

It’s an early step. Good chance it doesn’t work well in humans, and many side effects can’t be discovered until human trials either.

Vertragsrecht get da normalerweise von der Erwartungshaltung aus.
Bei Autos ist abschleppen und Bußgeld typisch. Aber niemand geht bei dem einfachen Nutzungsvertrag für Eintrittsgeld von Bußgeldern aus die zentausend mal höher liegen, oder überhaupt von Bußgeldern. Das ist die selbe Logik die dich davor schützt dass jemand so ne Klausel irgendwo böswillig versteckt.
Ich kann ja auch nicht nen Laden aufmachen dann in die Hausregeln setzen dass wer mit dem Linken Fuß eintritt sich verplichtet mir ne Million zu zahlen Frist 3 Jahre dann 3 Jahre später hunderttausen Kunden verklagen.

Also das Recht geht korrekterweise davon aus das quasi keiner so Verträge ließt oder versteht, also wenn ne typische person nicht erwarten würde was drin steht wirds schwer.

Wenn man jetzt beim Eintritt jedem verbal den Kern erklärt und nen Zettel unterschreiben lässt auf dem groß steht “Ich zahl Jedem den ich hier ohne deren Erlaubniss filme oder photographiere 1000,-€” dann vielleicht. Aber dann verschreckt man sich die Kundschaft.
Und am Ende kommt man wahrscheinlich trotzdem mit jeder wackeligen Ausrede da raus.

Rage!

Since noone went into details on it yet,
LCDs are already transparent. They filter light, and usually their back is simply lit uniformly white. Instead you can use them freestanding and get a pane of glass you can selectively darken. This is sometimes used in custom pc cases to show info on a glass sidepanel.

Unfortunately the way LCDs work means they always darken by 50% at the brightest, much more if you add color filters to escape b/w hell. If eink develops further and matches lcds in speed, it is probably possible to change the materials in one to make the pigment not block light when it is on one side.

As for getting brighter, that is on the edge of viable, since we are just short of microled screens. There are already larger screens using that technology, and if you really wanted to you could make small screens too, it would just be really expensive and manual. Viable mass production is still in development, current methods have too many dead pixels.

So within a few years and with some development to adjust eink to the purpose, it should be possible to get a pretty transparent pane that can become opaque and specular or matte in any color and saturation and brightness, and also emit light at will on its surface.

The driver electronics should be very shrinkable and could probably be made small enough you literally couldn’t see them. The limit is probably gonna be the power source, which will likely have to wait for some far off material science magic like graphene capacitor batteries that manages to make it transparent so you can stick it inside the pane of glass.

Glaub nicht dass man einfach so Strafzahlungen in Hausregeln einbetten kann. Neben Hausverbot ist da wohl nicht viel drin.
Vielleicht kann man das legal öffentlich bekannt machen und Täter so an den Pranker stellen…

Females

jucky.

Also probably a function of the intended audience. Only happens when content farming stuff that hits a certain audience, and then it’s equally done by all creators. If you’re not an attractive woman you just put someone else in the thumbnail, like someone you interviewed, or if it’s game-related a character.

Don’t do it often enough to remember which is better and which is worse. The first search result isn’t garbage enough to bother with something else.

In those cases it’s less painfull to use a website to extract the transcript and read that.
You can skim around text way easier than a video.

TLDR: ddr ram refreshes itself, making cpus freeze sometimes when reading ram. High speed traders don’t want that so they figure out ways to make data live with two copies on two different portions of ram that freeze at different times. This is impractical for normal programs. Most of the effort is spent on working around multiple abstraction layers, where the os and then the ram itself changes where specifically data goes.

Every 3.9 microsconds, your RAM goes blind. Your RAM physically has to shut down to recharge.
This lockout is defined by the Jedex spec as TRFC or refresh cycle time. Now, a regular read on DDR5 might take you like 80 nanoseconds. But if you happen to accidentally get caught by this lockout, that’s going to bump you up to about 400 nanoseconds.

Think for a second. What industry might really care about wasting a couple hundred nanconds where one incorrectly timed stall would cost you millions of dollars? That’s right, the world of highfrequency trading.

[custom benchmark program on ddr4 ram and 2.65GHz cpu:] When you plot the gaps between the slow reads, they’re all the same, 7.82 microsconds [20,720 cycles] apart every single time. […] So, the question is, if this is so periodic, can we potentially predict when the refresh cycle is going to happen and then try to read around it?

See, it’s not like the whole stick of RAM gets locked when the refresh cycle happens. It’s a lot more granular than that. With DDR4, for example, the refresh happens at the rank level. And then DDR5 gets even more complicated where you can like subsection down even further than that.

The memory controller does what’s called opportunistic refresh scheduling, which basically means that it can postpone up to eight refreshes and then catch up later if we happen to be in a busy period. […] how the heck are you going to predict opportunistic refresh scheduling?

Then stuff about virtual memory management in modern OSs

And I take two copies of my data and I space them nicely 128 bytes apart. And I’m feeling pretty good about myself, but for all I know, it could be straddling a page boundary and then the OS could have decided to put them wherever it felt like putting them.

physical ram address issues:

So the exor [XOR?] hashing phase kind of acts like a load balancer baked like directly into the silicon itself. Takes in your physical address, does a little bit of scrambling, and tries to spread it out evenly across all of the banks and channels.

This also helps with rowhammer attacks where writing close to a physical address lets you write to that other address.

So, DRAM [XOR] hashing strategies were already not documented publicly. But then after the entire rowhammer thing, obviously, there was even less incentive to publish these load balancing math strategies publicly.

If AMD and Intel documented this kind of stuff, they’d kind of be like locking themselves into a strategy because customers would start to build against it. And then next year when it comes around, it’s really going to make your life difficult because you’re not going to be able to change things nearly as easily. But if you just don’t document it, well, who’s going to complain? only weirdos doing crazy stuff like me.

Inside of your CPU, right next to the memory controllers, there’s actually tiny little hardware counters, one for every channel. […] If we do a simple pseudo [sudo] modprobe AMD uncore, it reveals those hardware counters to the standard Linux Perf tool. […] If I write a tight loop of code that constantly flushes the cache and hammers one particular memory address, then that means one counter should start to light up. And theoretically, this should tell us exactly what channel that our data is living on.

Can’t really tell what’s going on here. Well, that, my friend, is OS noise. […] The problem is these counters are pretty dumb. So you can’t tell it only count the reads from this particular process. […] All we need to do is run it 50,000 times. […] See that spike? Super cool. And now I really know where my data lives.

So, to me, I don’t really care which channel I’m ending up on, whether that’s channel 3, channel 7, whatever, doesn’t matter to me. All I need to do is make sure I’m ending up on different channels. […] The mathematical answer is that XOR is linear over GF2 which is actually really simple. Basically that means that no matter what scrambling the memory controller does, flipping a base bit will always flip the output no matter how many things are chained together.

Goes on to write low latency benchmarks which show lower latency.

I though this was a regex command and kept wondering what “girll” means.