On Wed, Jan 13, 2016 at 04:40:31PM -0700, Eric Blake wrote: > On 01/12/2016 11:56 AM, Daniel P. Berrange wrote: > > Add a generic framework for support different block encryption > > formats. Upon instantiating a QCryptoBlock object, it will read > > the encryption header and extract the encryption keys. It is > > then possible to call methods to encrypt/decrypt data buffers. > > > > There is also a mode whereby it will create/initialize a new > > encryption header on a previously unformatted volume. > > > > The initial framework comes with support for the legacy QCow > > AES based encryption. This enables code in the QCow driver to > > be consolidated later. > > > > Signed-off-by: Daniel P. Berrange <berra...@redhat.com> > > --- > > > +++ b/qapi/crypto.json > > @@ -94,3 +94,68 @@ > > { 'enum': 'QCryptoIVGenAlgorithm', > > 'prefix': 'QCRYPTO_IVGEN_ALG', > > 'data': ['plain', 'plain64', 'essiv']} > > + > > +## > > +# QCryptoBlockFormat: > > +# > > +# The supported full disk encryption formats > > +# > > +# @qcowaes: QCow/QCow2 built-in AES-CBC encryption. Do not use > > +# > > Well, the only reason to use it would be to read data off an old > insecurely-encrypted qcow2 file; so maybe it should read "Do not use on > new files"
Yep > > +# Since: 2.6 > > +## > > +{ 'enum': 'QCryptoBlockFormat', > > +# 'prefix': 'QCRYPTO_BLOCK_FORMAT', > > + 'data': ['qcowaes']} > > Would 'qcow-aes' be any easier to read? Or just shorten to 'qcow' perhaps ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|