MSDN 示例：这是错误还是优化（X509Certificate2 类）
我正在查看此 MSDN 页面中的好示例： http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.aspx
滚动向下到示例的一半并查看该方法：
// Decrypt a file using a private key.
private static void DecryptFile(string inFile, RSACryptoServiceProvider rsaPrivateKey)
您会注意到读取器在尝试从流中读取 int 时一次仅读取 3 个字节：
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
由于下一行是寻求位置“4”，因此该错误正在被蒙蔽。我是否理解正确，或者，它是故意的，即某种奇怪的优化，因为我们知道（对于这个例子）AES 密钥和 IV 的长度将足够小，可以容纳 3 个字节，因此只读取 3 个字节，然后跳过到 4，从而节省从磁盘读取 1 个字节？
如果优化....真的吗？
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??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我非常怀疑这是一种优化。磁盘读取往往是远大于四个字节的块，并且缓存几乎会使这种类型的优化无效，除非在极少数情况下，四个字节可能跨越两个不同的磁盘“扇区”（或者无论磁盘读取分辨率如何） ）。
这种范例往往出现在（例如）仅使用三个字节并且实现在那里存储其他信息的地方。
并不是说这里的情况就是这样，但你可能想研究一下某些大公司为自己的目的使用字段的历史，不管标准怎么说，“拥抱、延伸、消灭”:-)
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" :-)