3 ms·
Yup, mass cloning a VM is really bad if you rely on stream ciphers for communication over the Internet and you do not instantly reseed. Suddenly you'll have ton
by Natanael_L 11y ago
Yup, mass cloning a VM is really bad if you rely on stream ciphers for communication over the Internet and you do not instantly reseed. Suddenly you'll have tons of identical keystreams otherwise, making plaintext recovery trivial.
Your VM host simply must instantly inject unique entropy into each VM guest instantly on creation, duplication and start. Otherwise you're breaking your own security.
- xorcist 11y agoIt also makes #2 above hard in practice. You simply don't know when to block. That's one of the reasons Linux developers are, shall we say, conservative with regards to the entropy pool. On a recent Linux environment those problems are solved however. Use proper random drivers for your virtualized environment and use getrandom() in your application.
- infogulch 11y agoCould the host set a 'dirty entropy' flag whenever it creates/duplicates/starts a new VM? The VM could then watch for this flag and reseed when it notices.
- Natanael_L 11y agoThe solution in use now is that the guest OS asks the VM host for entropy using its VM guest specific kernel drivers, to seed the CSPRNG of the guest. If you have it do that on every guest RNG request you'll get the same desired effect without adding more communication. When you duplicate any VM guest, all sensitive key material should be replaced instantly (preferably never copied to begin with, the host should generate and inject fresh key material). Refilling the entropy pool alone isn't enough when reuse-insecure ciphers like stream ciphers are actively used, for the reasons stated above. Some ciphers are more tolerant of reuse (see AES-GCM vs AES-GCM-SIV).