HDD GURU FORUMS
http://forum.hddguru.com/

why flash manufacturers encrypt chips?
http://forum.hddguru.com/viewtopic.php?f=10&t=42797		 Page 1 of 2
Author:  underdeath21 [ October 16th, 2022, 20:40 ]
Post subject:  why flash manufacturers encrypt chips?
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?
Author:  arvika [ October 17th, 2022, 1:20 ]
Post subject:  Re: why flash manufacturers encrypt chips?
You mean encryption or scrambling (xoring data)?
Author:  Arch Stanton [ October 17th, 2022, 19:30 ]
Post subject:  Re: why flash manufacturers encrypt chips?
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?
Author:  fzabkar [ October 18th, 2022, 0:29 ]
Post subject:  Re: why flash manufacturers encrypt chips?
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?).
Author:  Arch Stanton [ October 18th, 2022, 6:38 ]
Post subject:  Re: why flash manufacturers encrypt chips?
fzabkar wrote:
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?
Author:  pepe [ October 19th, 2022, 12:48 ]
Post subject:  Re: why flash manufacturers encrypt chips?
Quote:
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
Author:  Arch Stanton [ October 20th, 2022, 5:13 ]
Post subject:  Re: why flash manufacturers encrypt chips?
pepe wrote:
Quote:
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.
Author:  rec [ October 22nd, 2022, 17:13 ]
Post subject:  Re: why flash manufacturers encrypt chips?
Arch Stanton wrote:
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
Author:  rec [ October 22nd, 2022, 17:34 ]
Post subject:  Re: why flash manufacturers encrypt chips?
fzabkar wrote:
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...
Author:  Arch Stanton [ October 22nd, 2022, 17:38 ]
Post subject:  Re: why flash manufacturers encrypt chips?
rec wrote:
Arch Stanton wrote:
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

Attachment:
xor-block.png
xor-block.png [ 200.47 KiB | Viewed 7923 times ]


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.
Author:  rec [ October 23rd, 2022, 7:45 ]
Post subject:  Re: why flash manufacturers encrypt chips?
Based on the pictures shown I guess that you are doing the XOR operation with a varying source and not with any byte value.
Author:  Arch Stanton [ October 23rd, 2022, 7:55 ]
Post subject:  Re: why flash manufacturers encrypt chips?
I have no idea what this means or what you mean to tell by it.
Author:  rec [ October 23rd, 2022, 11:14 ]
Post subject:  Re: why flash manufacturers encrypt chips?
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.
Author:  Arch Stanton [ October 23rd, 2022, 11:27 ]
Post subject:  Re: why flash manufacturers encrypt chips?
Depends on what you pick to XOR with, you assume everything is xor-ed with same byte or am I mistaking?
Author:  Arch Stanton [ October 23rd, 2022, 11:30 ]
Post subject:  Re: why flash manufacturers encrypt chips?
you really don't get my point about introducing 'noise' or are you just fucking about?
Author:  rec [ October 23rd, 2022, 12:52 ]
Post subject:  Re: why flash manufacturers encrypt chips?
Arch Stanton wrote:
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.

Arch Stanton wrote:
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.
Author:  Arch Stanton [ October 23rd, 2022, 16:04 ]
Post subject:  Re: why flash manufacturers encrypt chips?
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.
Author:  rec [ October 24th, 2022, 6:20 ]
Post subject:  Re: why flash manufacturers encrypt chips?
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.
Author:  Arch Stanton [ October 24th, 2022, 6:41 ]
Post subject:  Re: why flash manufacturers encrypt chips?
rec wrote:
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.
Author:  HaQue [ November 17th, 2022, 8:28 ]
Post subject:  Re: why flash manufacturers encrypt chips?
There are research papers on this stuff you can read.
Page 1 of 2 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/