The Side Channel

« first day (3513 days earlier) ← previous day next day → last day (1168 days later) »

1:26 AM

This is completely wrong. Not only does a 4 byte HMAC not provide security against intentional modification (only a full HMAC can do that), but it is more vulnerable to accidental collisions as an n-bit CRC is guaranteed to detect any burst errors up to length n + 1, with the sole exception of the case where the CRC polynomial divides the burst error polynomial. — forest 5 mins ago

As usual, someone with a lot of rep and an upvoted post who does not understand that 4-byte truncated HMAC is insecure and misunderstands CRC burst error detection. I commented...

forest

1:38 AM

A: Is CRC pointless if I'm doing truncated HMAC?

Assuming you don't care about collisions (which would be the case if you used a 4-byte HMAC), a CRC is actually better for detecting accidental errors. An n-bit CRC is guaranteed to detect any burst error up to n + 1 bits in length, with the sole exception of a burst error whose polynomial divide...

Wrote my own answer, but I doubt it'll get the upvotes that the incorrect top answer did. :/

b degnan

2:17 AM

@forest the scan lines will be pretty easy to see in theory. Having said that, the frequency is so low you might need special equipment. My RF equipment runs from 100Hz to 10GHz. I don't have anything around the lab that can do a keyboard as it falls into the mixer floor. Basically, you are looking for some MHz pulse from the lines on the order of <10Hz. That's sorta the definition of static.

btw, Forest, I'm going to see if I can get an answer for you for infosec from a FLASH IC that I have here. I'll see how long I have to tunnel it until I cannot see the offsets.

forest

2:37 AM

@bdegnan Oh thanks!

What device/model?

But it'll be very interesting to see some empirical data for a subject that's so poorly understood as flash/EEPROM data remnance (at least in the infosec sphere).

10 hours later…

b degnan

12:52 PM

@forest It's a test cell from a run on 14nm SOI. It's NOR, but not NAND. The only reason to look at this is that I have a debug framework already and it'll take me very little time. Also, it differs as it tunnels to make the node positive because it has an on-chip charge pump.

I don't believe it's poorly understood, I have tons of data on this from 350nm in an analog context, but there's only a small group of us who do FLASH. I really haven't done any in 10 years, but it's likely the same.

5 hours later…

JBis

6:18 PM

Hello

kelalaka

6:58 PM

Hi @JBis

JBis

I have a problem. Similar to Yao's Millionaires' problem.

Alice and Bob may want to go on a date together. But it would be embarrassing for either of them to be rejected. So Alice and Bob choose either 1, for "I would go on a date" or 0 for "I would not go on a date". Alice and Bob need to compare their values in a way where neither would know if they they rejected the other.

Sorta like a private AND gate. Like, A and B can be 1 or 0. A and B are put through a function which returns 1 if and only if A and B are 1. However, if one party is 0 they don't know if the other party is 1 or 0.

kelalaka

You know you are rejected if you choose 1 but the return is 0.

JBis

@kelalaka That is ok, because no one else would know you were rejected.

kelalaka

Then why don't you just send the values to each other securely?

JBis

7:14 PM

Because if Alice rejects Bob and knows about it, she could publish it and embarrass Bob.

kelalaka

But this conflict to the case Alice choose 1 and rejected. She will alredy know since you sent here rejected.

In MPC, only missing case, Alice rejects. She can never learn the Bob either rejected her or not.