why flash manufacturers encrypt chips?

[underdeath21]

i heard stories that flash manufacturers factory encrypt their chips and making data recovery.
is there any reason why some manufacturers encrypt their chips..what does it give them?

[arvika]

You mean encryption or scrambling (xoring data)?

[Arch Stanton]

Maybe for same reason hard drive manufacturers do this.

Also I have been wondering if encryption accomplishes the same as XOR scrambling.. XOR scrambling serves a purpose, say increase of entropy. Could encryption do the same?

[fzabkar]

FDE typically uses AES. A sector full of zeros, after encryption, is filled with a repeating pattern of 16 bytes. Those 16 bytes have high entropy, but the sector does not (or does it?).

[Arch Stanton]

FDE typically uses AES. A sector full of zeros, after encryption, is filled with a repeating pattern of 16 bytes. Those 16 bytes have high entropy, but the sector does not (or does it?).

Ah, good to know. That would answer my question then I guess with 'no'. So then I suppose these manufactures apply both encryption on top or after some kind of scrambling?

[pepe]

is filled with a repeating pattern of 16 bytes.

only if AES-ECB is used, but there are ways to do it better, like AES-CBC , CFB, etc, so it would result in a high-entropy data block.
pepe

[Arch Stanton]

is filled with a repeating pattern of 16 bytes.

only if AES-ECB is used, but there are ways to do it better, like AES-CBC , CFB, etc, so it would result in a high-entropy data block.
pepe

Interesting.

[rec]

Maybe for same reason hard drive manufacturers do this.

Also I have been wondering if encryption accomplishes the same as XOR scrambling.. XOR scrambling serves a purpose, say increase of entropy. Could encryption do the same?

I don't understand why a XOR operation increases entropy. Could you explain?

As for your encryption question the answer is yes if you use the right mode, see here:
https://github.com/pakesson/diy-ecb-penguin

[rec]

FDE typically uses AES. A sector full of zeros, after encryption, is filled with a repeating pattern of 16 bytes. Those 16 bytes have high
entropy, but the sector does not (or does it?).

The sector could be compressed easily without loss. That is low entropy on sector level and above.
I wonder if one would apply the term entropy on a 16 byte pattern only...

[Arch Stanton]

Maybe for same reason hard drive manufacturers do this.

Also I have been wondering if encryption accomplishes the same as XOR scrambling.. XOR scrambling serves a purpose, say increase of entropy. Could encryption do the same?

I don't understand why a XOR operation increases entropy. Could you explain?

As for your encryption question the answer is yes if you use the right mode, see here:
https://github.com/pakesson/diy-ecb-penguin

Maybe I should have avoided that word, but if we XOR block of zeros with XOR key or block, do we not increase entropy? AIUI storing very similar data close is more prone to corruption and to avoid this XOR is applied to introduce noise and avoid worst case patterns. I assumed this increase in noise leve translates to high Shannon entropy. But I am no expert on the matter, it's what I read everywhere (NAND Flash Data Recovery Cook Book and other places / documents). If we look at typical XOR-ed block of repeating bytes in VNR we see

Which seems to me higher entropy data than a repeating pattern. If the same is already accomplished by some form of encryption XOR scrambling seems like an un-needed extra step. So maybe reasoning is, encryption gives us required noise AND we can position/market encryption as a feature. I do not know, I am simply guessing, thinking out loud.

[rec]

Based on the pictures shown I guess that you are doing the XOR operation with a varying source and not with any byte value.

[Arch Stanton]

I have no idea what this means or what you mean to tell by it.

[rec]

The pictures to the right look like noise to my eye. It looks as if the content of all bytes are equally distributed. I assume that compression would no be able to reduce the size of the underlying files.

Now look at my two sentences above in ASCII-code. XORing each byte with a fixed value from the range [0:255] will certainly modify the appearance but will not affect the form of the distribution. The most frequent letter will be represented by a different value but will represented as often as before performing the XOR operation.

[Arch Stanton]

Depends on what you pick to XOR with, you assume everything is xor-ed with same byte or am I mistaking?

[Arch Stanton]

you really don't get my point about introducing 'noise' or are you just fucking about?

[rec]

Depends on what you pick to XOR with, you assume everything is xor-ed with same byte or am I mistaking?

Yes, that is correct.

you really don't get my point about introducing 'noise' or are you just fucking about?

I am asking the question because I get the idea but I wonder how running a byte-wise XOR should introduce noise.

[Arch Stanton]

AIUI NAND uses 'XOR keys'. Let's XOR a low entropy pattern xFF xFF xFF xFF with 'key' x12 x34 x56 x78, we get xED xCB xA9 x87. If we use 512 byte XOR key we introduce noise or entropy in low entropy blocks.

[rec]

I agree. And what you did even corresponds to one-time pad encryption.

But I was thinking about taking a drive sector and XOR it with 'key' x12 x34 x56 x78.
That does not really increase entropy.

[Arch Stanton]

I agree. And what you did even corresponds to one-time pad encryption.

But I was thinking about taking a drive sector and XOR it with 'key' x12 x34 x56 x78.
That does not really increase entropy.

Since you assumed XOR-ing every byte with same byte over and over I gave 4 byte example. I could also have given 8 byte, or 16 byte or 256 byte example but was too lazy and figured you'd get the idea. If you need entropy in larger block you use bigger XOR key.

[HaQue]

There are research papers on this stuff you can read.