Earlier quoted context omitted.
> Is this exploitable through JavaScript? Why wouldn't it be?
How is JavaScript going to run a chosen-input attack against one of your cores for an hour?
If you leave a tab open that's running that JS..
GoFetch: New side-channel attack using data memory-dependent prefetchers
81–90 of 100 posts
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#82Earlier quoted context omitted.
> Is this exploitable through JavaScript? Why wouldn't it be?
Because JS/html provides APIs to perform cryptography(I can't recall whether the cryptography specs are part of ES or HTML/DOM) - if you try to implement constant time cryptography in JS you will run into a world of hurt due to the entire concept of "fast JS" being dependent on heavy speculation, and lots of exciting variations in timing of even "primitive" operations.
No, the attack would be implemented in JS, not the victim code (though, that too, but that's not what's interesting here).
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#83As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in…
Speaking as a cryptography implementer, yes, these drive us up the wall. However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc. Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? D…
Wouldn't that "just" allow someone to see if a key was present (and any information that informs) but dramatically help prevent secret key extraction?
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#84Why does Apple have so many hardware backd... innocent bugs?
why do we even need caches? why do we need prefetchers? But in answer to your bullshit backdoor conspiracy theory (JFC processors have caches and timing variants because people want fast CPUs, you cannot have constant time and fast, apple is not the only company with prefetchers), here's some apple provided documentation on how disable the hardware backd... enable constant time operations specifically for the purpose…
The M1 and M2 don't have that bit.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#85Earlier quoted context omitted.
Why does the comments of every such attack need a question about why it has its own branding, marketing page, etc…? Genuine question. (Seriously, this comes up every time, just do a search for it if you actually want to figure out why.)
Because it makes it feel like you need some marketing department if you want to publish your work. Rather than give _only_ the work merit, we give too much merit to its colorful presentation. That shouldn't be the case.
Good communication has always been a part of making sure your work is influential.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#86Earlier quoted context omitted.
Because JS/html provides APIs to perform cryptography(I can't recall whether the cryptography specs are part of ES or HTML/DOM) - if you try to implement constant time cryptography in JS you will run into a world of hurt due to the entire concept of "fast JS" being dependent on heavy speculation, and lots of exciting variations in timing of even "primitive" operations.
No, the attack would be implemented in JS, not the victim code (though, that too, but that's not what's interesting here).
Ah, you’re concerned about person using js to execute the side channel portion of the attack, not the bit creating the side channel :)
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#87Earlier quoted context omitted.
It's probably in a MSR accessible from the kernel?
It seems to be userspace accessible: https://developer.apple.com/documentation/xcode/writing-arm6... The kernel would have to be aware of it in order to be able to restore its state across context switches though, unless it's part of a set of registers that is automatically persisted. But given that Apple is publicly documenting this flag, I suppose it is. Here's an interesting conversation by the Go developers from…
No, that’s something else. I’m talking about the thing that disables DMP, which would not be part of the standard architecture.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#88As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in…
Speaking as a cryptography implementer, yes, these drive us up the wall. However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc. Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? D…
> processor designers "just" need to stop violating assumptions
"Security" rarely (almost never) seems to be part of any commercially-significant spec.
Almost as if by design...
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#89From the paper: "OpenSSL reported that local side-channel attacks (...) fall outside of their threat model. The Go Crypto team considers this attack to be low severity".
At least one Go crypto developer publicly expressed concern about this very issue in 2021: https://github.com/golang/go/issues/49702
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#90So malware scanning and virus scanners just became relevant for Macs and IPads.
(Compromise must be running on the same hardware.)