Comment by pizlonator
12 days 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."
It 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!
OCB 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.
IIRC 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.
1 reply →
> It would be very surprising to see someone use OCB when GCM exists and is what everyone uses.
That is reassuring