4 ms·
Impressive. I checked the stack overflow that was marked High, and Fil-C prevents that one. One of the out-of-bounds writes is also definitely prevented. It'
by pizlonator 9mo ago
Impressive.
I checked the stack overflow that was marked High, and Fil-C prevents that one.
One of the out-of-bounds writes is also definitely prevented.
It's not clear if Fil-C protects you against all of the others (Fil-C won't prevent denial of service, and that's what some of these are; Fil-C also won't help you if you accidentally didn't encrypt something, which is what another one of these bugs is about).
The one about forgetting to encrypt some bytes is marked Low Severity because it's an API that they say you're unlikely to use. Seems kinda believable but also ....... terrifying? What if someone is calling the AESNI codepath directly for reasons?
Here's the data about that one:
"Issue summary: When using the low-level OCB API directly with AES-NI or
other hardware-accelerated code paths, inputs whose length is not a multiple
of 16 bytes can leave the final partial block unencrypted and unauthenticated.
Impact summary: The trailing 1-15 bytes of a message may be exposed in
cleartext on encryption and are not covered by the authentication tag,
allowing an attacker to read or tamper with those bytes without detection."
- arcfour 9mo agoIt would be very surprising to see someone use OCB when GCM exists and is what everyone uses. Although I agree in principle it is quite scary!
- pizlonator 9mo ago> It would be very surprising to see someone use OCB when GCM exists and is what everyone uses. That is reassuring
- SAI_Peregrinus 9mo agoOCB can be a bit faster than GCM, the only reason GCM took over is because OCB was patented. That patent has now lapsed, but since everyone uses GCM the performance advantage of OCB isn't likely worth switching for. Especially since GCM has hardware acceleration, and IIRC OCB can't benefit from that so it may actually decrease performance on modern CPUs.
- arcfour 9mo agoIIRC GCM offers additional authenticated data whereas OCB doesn't (or you would have to roll it yourself), right? That would be another reason to pick GCM over OCB.
- SAI_Peregrinus 9mo agoOCB3 also allows associated data (AD). Rogaway's faq[1] describes the history of the versions. OCB1 didn't have AD, OCB2 tried to fix that but was less efficient. OCB3 is the final version of OCB, and is a proper AEAD cipher. After OCB3 was created OCB2 was broken, but OCB1 and OCB3 remain secure. OCB3 is provably secure, and at least 2x as fast as GCM without hardware acceleration. In theory it'd be faster with hardware acceleration, but that's only likely in an FPGA or ASIC implementation since GCM is fast enough and accelerated in modern CPUs. Intel & AMD aren't going to spend the die area on OCB. I like OCB, it's an elegant construction, but I'm more likely to use and recommend GCM because GCM is good enough and allows much easier interop since it's more widely used. Since AEGIS is nicer as a high-performance cipher system, and Ascon is better for constrained systems OCB doesn't really have a niche where it's the best choice. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm