Hi to all and excuse me for delay but lately the life seems to me more
complicated :-D
Coming to us, I've repeat all procedure using Cryptsetup 2.3.3, with the
same tutorial -> "http://www.sourcentral.org/luks/iso9660/"; and the
results seems the same, as you can see:
cryptsetup --debug -r luksOpen image.iso volume1
# cryptsetup 2.3.3 processing "cryptsetup --debug -r luksOpen image.iso
volume1"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device image.iso.
# Trying to open and read device image.iso with direct-io.
# Trying to open device image.iso without direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device image.iso.
# Crypto backend (OpenSSL 1.1.1f 31 Mar 2020) initialized in
cryptsetup library version 2.3.3.
# Detected kernel Linux 5.8.0-25-generic x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device image.iso.
# Verifying lock handle for image.iso.
# Device image.iso READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device image.iso
# Veryfing locked device handle (regular file)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:47874913fa24493aa71dc39d3ff41d1dc1f36719eea32c2fb1b6a1aef1a09ac9
(on-disk)
#
Checksum:47874913fa24493aa71dc39d3ff41d1dc1f36719eea32c2fb1b6a1aef1a09ac9
(in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device image.iso
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
#
Checksum:29975a514962a03e116133c091e725a47e5b6ccb077cf6e1502a259618737297
(on-disk)
#
Checksum:29975a514962a03e116133c091e725a47e5b6ccb077cf6e1502a259618737297
(in-memory)
# Device size 16777216, offset 16777216.
# Device image.iso READ lock released.
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# PBKDF argon2i, time_ms 2000 (iterations 0), max_memory_kb 1048576,
parallel_threads 2.
# Activating volume volume1 using token -1.
# Interactive passphrase entry requested.
Enter passphrase for image.iso:
# Activating volume volume1 [keyslot -1] using passphrase.
# dm version [ opencount flush ] [16384] (*1)
# dm versions [ opencount flush ] [16384] (*1)
# Detected dm-ioctl version 4.42.0.
# Detected dm-crypt version 1.21.0.
# Device-mapper backend running with UDEV support enabled.
# dm status volume1 [ opencount noflush ] [16384] (*1)
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Reading keyslot area [0x8000].
# Acquiring read lock for device image.iso.
# Verifying lock handle for image.iso.
# Device image.iso READ lock taken.
# Reusing open ro fd on device image.iso
# Device image.iso READ lock released.
# Verifying key from keyslot 0, digest 0.
# Loading key (64 bytes, type logon) in thread keyring.
# dm versions [ opencount flush ] [16384] (*1)
# dm status volume1 [ opencount noflush ] [16384] (*1)
# Allocating a free loop device.
# Trying to open device /dev/loop6 without direct-io.
Requested offset is beyond real size of device image.iso.
# Requesting keyring logon key for revoke and unlink.
# Releasing crypt device image.iso context.
# Releasing device-mapper backend.
# Closing read only fd for image.iso.
# Closed loop /dev/loop6 (image.iso).
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters).
I've not tested jet the Carlos way, but in the next days I will let you
know:
"Carlos E. R." ha scritto:
Hum. I created encrypted DVD years ago with a similar procedure,
somewhat simpler. Basically, I created an empty file of the same size
as
the CD or DVD, mounted it as a loop device, then I encrypted that loop
device, and then I formatted the resulting luks device with any
filesystem type I wished, typically XFS.
This, so far, still works.
Then I just burn that file to DVD.
and
"Milan Broz" ha scritto:
Are you sure that your *.iso image was correctly created? It seems to
me that
it is just LUKS header without data (that's why "beyond offset" error).
Milan
No I'm not sure, indeed I think it's as you say. And I think this is a
block size problem almost certainly!
Eventually if you have any other way, maybe tested by you, for the
creation of encrypted cdroms/cdvs, would you please me ;-)
Many thanks!
Davide
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
