hovav

5 ms·

1.
by hovav 11mo ago
> has already been patched against ... has not been (effectively) patched against, as it happens. Maybe in December!
2.
by hovav 1y ago
Standard operating procedure for both the Chrome [ https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... ] and Firefox [ https://www.mozilla.org/en-US/about/governan
3.
by hovav 1y ago
> Xiaogang (Cliff) Wang is listed as the principal investigator. No, you are misreading the award abstract. Cliff Wang is the program manager at NSF who is the point of contact for the investigators.
4.
by hovav 2y ago
It's not guaranteed. See section 7 of https://www.usenix.org/system/files/conference/usenixsecurit...
5.
by hovav 2y ago
> power need[s] to be exploited locally Not in the presence of DVFS, it turns out: https://www.hertzbleed.com/hertzbleed.pdf
6.
by hovav 3y ago
Abersoft Forth for the ZX Spectrum inspired one of the classic books about Forth, Don Thomasson's /Advanced Spectrum FORTH/ (1984): https://archive.org/details/AdvancedSpectrumFORTH
7.
by hovav 3y ago
Levine's /Linkers and Loaders/ is a great book, but it's still in print, and this is an unauthorized copy. The author's home page ( https://www.iecc.com/linker/ ) used to host a PostScript versio
8.
by hovav 3y ago
Yes! See, e.g., Fraser Brown et al., "Towards a Verified Range Analysis for JavaScript JITs," in proc. PLDI 2020, https://www.cs.utexas.edu/~hovav/dist/vera.pdf
9.
by hovav 3y ago
A JIT is a machine for turning logic bugs into memory unsafety. Rewriting a JIT in Rust won't eliminate logic bugs and won't guarantee memory safety for the binary output of the JIT (as distinct from the JIT implementation itself
10.
by hovav 3y ago
Even with a verifiably random key, Dual EC is still unacceptable. First, because its output has unacceptable biases [1,2]. Second, because its presence allows an attacker to create a difficult-to-detect backdoor simply by replacing the key,
11.
by hovav 3y ago
It would not help at all. See (all of, but especially) section 5.4 of N. Carlini, A. Barresi, M. Payer, D. Wagner, and T.R. Gross, "Control-Flow Bending: On the Effectiveness of Control-Flow Integrity," in proc. USENIX Security 2
12.
by hovav 3y ago
Indeed, the History of Documented Unix Facilities [ https://github.com/dspinellis/unix-history-man ] says a vi(1) man page first appeared in 2BSD, and vi is implemented (as part of ex, with a 1979 copyright) in 2BSD src&
13.
by hovav 3y ago
"Best Practices (BP) papers, up to 10 pages. Suitable papers are those that provide an integration and clarification of ideas on an established, major research area, support or challenge long-held beliefs in such an area with compellin
14.
by hovav 3y ago
X. Ren et al., "I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches," in proc. ISCA 2021: https://cseweb.ucsd.edu/~tullsen/isca2021.pdf
15.
by hovav 3y ago
It's listed as a summer deadline accepted paper for USENIX Security 2023: https://www.usenix.org/conference/usenixsecurity23/summer-ac... Per the call for papers [ https://www.usenix.org/confer
16.
by hovav 3y ago
See also the closely related "DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data," presented at Oakland last week: https://www.hertzbleed.com/2h2b.pdf
17.
by hovav 3y ago
See also the closely related "DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data," which will be presented at Oakland today: https://www.hertzbleed.com/2h2b.pdf (It&#x27
18.
by hovav 4y ago
I don't think Juniper used BSAFE in ScreenOS -- they seem to have put together their own Dual EC implementation on top of OpenSSL, sometime around 2008. (This doesn't change your point, of course.)
19.
by hovav 4y ago
Steven Galbraith's Mathematics of Public Key Cryptography : https://www.math.auckland.ac.nz/~sgal018/crypto-book/crypto-...