Reputation: 1453
I was looking at the good example in this MSDN page: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.aspx
Scroll down half way to the example and look into the method:
// Decrypt a file using a private key.
private static void DecryptFile(string inFile, RSACryptoServiceProvider rsaPrivateKey)
You will notice the reader is reading only 3 bytes at time while it is trying to read an int off the stream:
inFs.Seek(0, SeekOrigin.Begin);
inFs.Read(LenK, 0, 3);// <---- this should be 4
inFs.Seek(4, SeekOrigin.Begin);// <--- this line masks the bug for smaller ints
inFs.Read(LenIV, 0, 3); // <---- this should be 4
Since the next line is Seeking to position "4", the bug is getting masked. Am I getting it right or, is it intentional i.e. some sort of weird optimization since we know that (for this example) length of AES Key and IV is going to be small enough to be accomodated in 3 bytes so read only 3 and then skip to 4, thus save reading 1 byte off the disk?
If an optimization.... Really??
Upvotes: 0
Views: 168
Reputation: 881643
I very much doubt it's an optimisation. Disk reads tend to be in chunks substantially larger than four bytes, and caching would pretty much invalidate this type of optimisation, except in the very rare case where the four bytes may cross two different disk "sectors" (or whatever the disk read resolution is).
That sort of paradigm tends to be seen where (for example) only three bytes are used and the implementation stores other information there.
Not saying that's the case here but you may want to look into the history of certain large companies in using fields for their own purposes, despite what standards say, a la "embrace, extend, extinguish" :-)
Upvotes: 1