Tag Info

New answers tagged

-3

This sequence allowed me to access the data cryptsetup luksOpen /dev/sdb1 disk2 modprobe dm-mod vgchange -ay mount /dev/disk2/disk2 /disk2 So I offer the reward to the one who'll tell me how to make this change permanent.


3

You have to remember there are two layers of abstraction involved here. You don't "mount" an encrypted disk. You open the encrypted disk with cryptsetup (if you have the correct password). This will create a mapping of the de-crypted partition at /dev/mapper/foo. Then you can mount /dev/mapper/foo to your desired mountpoint (such as /disk2). These are two ...


0

To mount an encrypted drive you just have to identify your encrypted drive and partition (lets say it is sdb1). Run the command cryptsetup luksOpen /dev/sdb1 EncHDD You will have to introduce your passphrase and a new device will be created under /dev/mapper called EncHDD. After that mount /dev/mapper/EncHDD /mnt and you will be ready to go. Your ...


0

Whatever you did to create /dev/sda2p2, it didn't do what you intended. You created a regular file in memory. In Linux's disk and partition naming convention, /dev/sda is a disk, /dev/sda2 is a partition on that disk. From the parted output, you currently have three partitions on that disk: a ~300MB partitionwhich is presumably /boot, a partition using most ...


0

Cracking Scrypt hashes is about 18,000X more expensive than cracking LUKS hashes when run for 200ms, when the attacker is using custom ASICs. To get the same protection by just increasing iterations, you'd have to let LUKS hash your password for an hour. Have fun with that :-) LUKS should switch to Scrypt as the default, plain and simple. Don't let the ...


3

dmsetup is useful for anything device mapper related. For Example: [root@localhost]~# dmsetup ls --target crypt luks-90dc732d-e183-4948-951e-c32f3f11b305 (253, 0) [root@localhost]~#


1

No. And even solutions that apparently do it without root privileges, actually do have root privileges. This is just a basic requirement for mounting or accessing raw disk data. If you could do those without root priveleges, you could read files you have no permission to read (by reading and searching the raw data), and if you could mount you could mess up ...


1

It's normal, depending on how the Initramfs was set up by your distribution. An Initramfs can be customized; so it could ask for the passphrase more often / indefinitely, or show a different message / force a reboot instead of just exiting init followed by the kernel panic. It actually already shows a message (the message is Wrong password, as opposed to ...


2

Yes. The init process, which always had process ID 1, exited. UNIX operating systems panic by design when this happens, because essentally, without init, the system cannot continue to do much of anything useful. (That's not technically quite true, some things can continue, but it's not supposed to happen and it considered bad enough to justify restarting the ...


1

From the cryptsetup manual: Removing the last passphrase makes the LUKS container permanently inaccessible. That's an inherent property of the design of LUKS. Each key slot contains the actual encryption key, wrapped by a key derived from the passphrase. If there is no slot left containing a wrapped key, then there is no copy of the key anymore. I'm ...


3

As the man page states, it's game over. Removing the last passphrase makes the LUKS container permanently inaccessible. That is, if you really removed the last key. Does cryptsetup luksDump show DISABLED for all key slots? Normally cryptsetup prevents you from doing that, or at least asks for confirmation: # cryptsetup luksRemoveKey foobar Enter ...


1

If you had an NTFS with data, and then luksFormated it, the first 129KiB of the NTFS have been overwritten by the LUKS header (even more if you added more than one passphrase) and thus the NTFS is likely damaged. If you don't have another copy of your data, you should stop everything at this point and go into a read-only recovery procedure. I'm not sure how ...


0

luks - create a new block device encrypted over existing block device. Not filesystem - so you can't mount it directly after opening. But - all data are lost. You can't encrypt existing ntfs partition. If you wish - you can encrypt device over sda, then open it with cryptsetup luksOpen /dev/sda1 crypted_sda1 and then mount /dev/mapper/crypted_sda1 ...


1

As far as I know you can't encrypt an existing partition with LUKS, so what you seem to have done is set the partition as encrypted, but you haven't mkfs'ed your new partition, reason for the mount: you must specify the filesystem type message.


0

This should do it, you will have to use sudo if you are not running this as root. cryptsetup openLuks /dev/mapper/sde /up2s3 You will be prompted for the password. openLuks is an abbreviated way of writing open --type luks When you are ready to unmount the drive, do cryptsetup close /up2s3. Doing this will erase the key from memory.



Top 50 recent answers are included