3 ms·
well you have to consider me (the designer, the guy putting the original code in the device that you want to verify and make sure that it's not someone else's c
by Taniwha 12y ago
well you have to consider me (the designer, the guy putting the original code in the device that you want to verify and make sure that it's not someone else's code) as trustworthy. After all I'm the one who's trying to protect the integrity of my product, I'm not going to give you a compressible bitstream if I can possible help it - and I'm going to publish the bitstream I am using so you can check
- toong 12y agoI think the parents point is that you generated the random-bitstream somehow, starting from a specific seed. If you know the seed, you could regenerates the random bitstream with a lot less bytes (=secretly compressible). So now you have some extra room left on the ROM to embed your malicious firmware and still be able to dump the original full 256k. If you start with a known image/photo (not yours, some public domain), that after encryption/compression is exactly the amount of padding you need (or cut-off), you have your padding-bitstream that is a lot harder to regenerate from a seed. Edit: clarification
- danbruc 12y agoGlad you asked - we have a book [1][2] for this, at least up to 405.5 KiB. [1] http://en.wikipedia.org/wiki/A_Million_Random_Digits_with_100,000_Normal_Deviates http://en.wikipedia.org/wiki/A_Million_Random_Digits_with_10... [2] http://www.amazon.com/Million-Random-Digits-Normal-Deviates/dp/0833030477 http://www.amazon.com/Million-Random-Digits-Normal-Deviates/...
- Taniwha 12y agoor we could use a hardware RNG ..... and run it through a whitener just to make it more interesting ....