Hello, > 10. Question - CRC is read in two places encryptionFileIO and > filePageStore - what should we do with this?
We need to calculate the CRC of encrypted data, because we may be using the wrong encryption key to decrypt data, in which case we will not understand if the physical integrity is violated or the wrong encryption key is used. > 9. Question - How do we optimize when we can check that this page is > already encrypted by parallel loading? Maybe we should do this in Phase 4? To do this, we need to store the encryption key ID in memory (at least), but this is not easy to do right now without breaking binary compatibility. > 7. Question -the current implementation does not use the throttling that > is implemented in PDS. Users should set the throughput such as 5 MB per > second, but not the timeout, packet size, or stream size. I've added a simple rate limiter for this. > 8. Question - why we add a lot of system properties? >> Can you, please, list system properties that should be moved to the >> configuration? It's about the background re-encryption properties, for now, it is: - re-encryption speed limit (in megabytes per second) - threads count used for re-encryption - count of pages in batch, processed under checkpoint lock - flag to completely disable background re-encryption > 11. We should remember about complicated test scenarios with failover PR contains tests for re-encryption (and key rotation) on unstable topology (with baseline change and without it). I'll expand them if I missed some cases. > 13. Will re-encryption continue after the cluster is completely stopped? Yes, as I mentioned earlier, we save the re-encryption status in the meta page of each re-encrypted partition and trigger re-encryption on node startup if needed (more detailed description on the wiki). Thanks a lot for your comments, I am still working on PR and expanding wiki documentation. I'll let you know when it will be ready for the review. вт, 28 июл. 2020 г. в 19:14, Alexey Goncharuk <alexey.goncha...@gmail.com>: > > Hello Nikolay, > > > > > 10. Question - CRC is read in two places encryptionFileIO and > > filePageStore - what should we do with this? > > > > filePageStore checks CRC of the encrypted page. This required to confirm > > the page not corrupted on the disk. > > encryptionFileIO checks CRC of the decrypted page(CRC itself stored in the > > encrypted data). > > This required to be sure the decrypted page contains correct data and not > > replaced with some malicious content. > > > > I still do not see why we need CRC twice, can you please elaborate on this > statement? If an attacker is able to replace the contents of an encrypted > page, it means that they have access to the encryption key. What will > prevent them from calculating the CRC of malicious content and then > encrypting it?
