On Tue, May 02, 2017 at 12:02:23PM +0100, Daniel P. Berrange wrote: > If we are encoding a block of data that is 16 bytes in length, > we cannot leave it as 16 bytes, we must pad it out to the next > block boundary, 32 bytes. Without this padding, the decoder will > incorrectly treat the last byte of plain text as the padding > length, as it can't distinguish padded from non-padded data. > > The problem exhibited itself when using a 16 byte passphrase > for a LUKS volume > > $ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \ > $(echo -n 1234567812345678 | base64) > Secret value set > > $ virsh start demo > error: Failed to start domain demo > error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16 > 2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \ > secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\ > keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \ > Incorrect number of padding bytes (56) found on decrypted data > > Notice how the padding '56' corresponds to the ordinal value of > the character '8'. > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > --- ACK Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
