I'm using ecryptfs to backup the entire contents of my Ubuntu box to an external hard drive enclosure. I've followed this guide and have things properly backing-up and encrypted as I want.
That's all well and good until I have to actually use the encrypted backup, and that's got me wondering. In the event that I lose my entire primary hard drive, what files/info should I readily have access to in order to de-crypt my backup? Besides the options used to setup the initial encryption, are these the only two things I need:?
passphrase
sig key
For a backup, you might just need to remember the passphrase and the options you used to set up the encrypted folder, so everything in the example page you linked:
To see the files again, just mount the directory with ecryptfs
filesystem.
# mount -t ecryptfs /home/sk/unixmen/ /home/sk/unixmen/
Select key type to use for newly created files:
1) tspi
2) passphrase
Selection: 2 <---- Type 2 and press enter
Passphrase: <---- Enter the passphrase
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32
2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]: <---- Press Enter
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]: <---- Press Enter
Enable plaintext passthrough (y/n) [n]: <---- Press Enter
Enable filename encryption (y/n) [n]: <---- Press Enter
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=5c116acdf1d0dd89
Mounted eCryptfs
The ecryptfs_sig is derived from the passphrase, so is really just to verify you've entered the right passphrase, not really essential to the mount command.
I can't say I like the "Add your passphrase in this file" part of the automatic mount section, detracts from the security by having the passphrase in plain text. Your system can use eCryptFS & PAM to automatically mount encrypted folders on login, using your login passphrase to "wrap"/encrypt the eCryptFS key. See man ecryptfs & the man pages for it's tools, like ecryptfs-setup-private
I found a much nicer solution, after struggling with the above for a couple of hours.
sudo ecryptfs-recover-private
It's super simple to use, just run it and it will find your old private directory, then mount it in /tmp for you.
From the man page:
ecryptfs-recover-private - find and mount any encrypted private directories
This utility is intended to help eCryptfs recover data from their encrypted home or encrypted private partitions. It is useful to run this from a LiveISO or a recovery image. It must run under sudo(8) or with root permission, in order to search the filesystem and
perform the mounts.
Related
I'm following the wiki https://help.ubuntu.com/community/Xen#Manually_Create_a_PV_Guest_VM
(section "
Set Up Initial Guest Configuration
")
I downloaded the netboot initrd.gz from https://mirror.arizona.edu/ubuntu//ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/xen/
but in the .cfg , what should I specify for the "disk = " line? ---- my host box is not using LVM, so I'll have to use "file-backed storage" for PV disk image. (https://wiki.xenproject.org/wiki/Storage_options , indeed this worked when I gave --dir= instead of --lvm= when running the xml-create command in https://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide )
here is my current config:
yy#yy-70A4000HUX:~/ub_xen$ cat ub_xen.cfg
name = "ubud1"
kernel = "/home/yy/ub_xen/vmlinuz"
ramdisk = "/home/yy/ub_xen/initrd.gz"
#bootloader = "/usr/lib/xen-4.4/bin/pygrub"
memory = 1024
vcpus = 1
# Custom option for Open vSwitch
vif = [ 'bridge=xenbr0' ]
disk = [ 'vdev=hda,target=/home/yy/ub_xen/images' ]
# You may also consider some other options
# [[http://xenbits.xen.org/docs/4.4-testing/man/xl.cfg.5.html]]
yy#yy-70A4000HUX:~/ub_xen$
I ran the command with sudo xl create -c ub_xen.cfg
this worked fine first, giving me the regular install process on console, pulling install files from remote archive, but when it comes to the step of disk paritioning, it's showing me a "SCSI" partitioning choice, with no volumes / partitions/disks to be chosen.
I guess this is because I'm not setting the right value for "disk = [ ]" option. what should I use here if I use file-backed storage for PV (just like VMware does)?
thanks a lot
Yang
found it, huge thanks to the author here: https://www.systutorials.com/create-and-manage-virtual-machines-on-xen/
I do that:
library(encryptr)
genkeys()
And I created the password: 0)]30l^8
password<-"0)]30l^8"
data(gp)
write.csv(gp, "gp.csv")
encrypt_file("gp.csv")
My problem is: How do I automatically enter the password on the decrypt_file("gp.csv.encryptr.bin", file_name = "gp2.csv")
I need this to decrypt many files in a short time.
Many thanks for the question. Saving a password in a script is not recommended as that defeats the purpose of encrypting a file in most circumstances. You can work around this intentional feature although it is not recommended.
password<-"0)]30l^8"
.crypt = readRDS("gp.csv.encryptr.bin") # in file
zz = file("gp2.csv", "wb") # out file
openssl::decrypt_envelope(.crypt$data, .crypt$iv, .crypt$session, key = "id_rsa", password = password) %>%
writeBin(zz)
close(zz)
I am trying to decrypt programmatically encrypted file using OpenSSL. OpenSSL was used to encrypt the file and I know both the function and the key that was used:
//This declaration is just figurative
const char keybuf = "12345678";
// Prepare the key for use with DES_cfb64_encrypt
DES_cblock key2;
DES_key_schedule schedule;
// keybuf is the string key used as password
memcpy(key2, keybuf, 8);
DES_set_odd_parity(&key2);
DES_set_key_checked(&key2, &schedule);
int n = 0;
DES_cfb64_encrypt( ..., ..., length, &schedule, &key2, &n, DES_ENCRYPT );
First I converted the file to binary from base64 (which is how it's packed):
cat data.b64 | base64 --decode > data.cr
Now when I run command line on encrypted data (assuming des-cfb is algorighm I need):
openssl enc -d -des-cfb -in data.cr -out data.decr -k 12345678
this is what I get:
bad magic number
So what I'm doing wrong here? Maybe I converted the file wrongly from base64?
Which openssl command is equivalent to DES_cfb64_encrypt function?
None
The CFB mode is a parametrized mode and the 64 in DES_cfb64_encrypt sets the size of the shift register or segment to 64 bit. The commandline interface only supports 3 segment sizes for CFB mode which are 1 bit, 8 bit and size of the cipher block size (64 bit for DES). Those three parametrized modes are incompatible between each other and they cannot be used to decrypt ciphertexts that were encrypted with CFB-64.
I am looking at this page on how to validate HMAC implementation on a platform: http://csrc.nist.gov/groups/STM/cavp/
Test Vectors:
HMAC Test Vectors - These files provide an electronic version of the test vectors
that can be used to informally verify the correctness of an HMAC algorithm
implementation using the HMACVS. However, use of these vectors does not
take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).
So I open up the file and view the test values:
http://pastebin.com/phJ4C0Fx
it is thousands of lines long but this is the start.
I focus on the first values:
[L=20]
Count = 0
Klen = 10
Tlen = 10
Key = 82f3b69a1bff4de15c33
Msg = fcd6d98bef45ed6850806e96f255fa0c8114b72873abe8f43c10bea7c1df706f10458e6d4e1c9201f057b8492fa10fe4b541d0fc9d41ef839acff1bc76e3fdfebf2235b5bd0347a9a6303e83152f9f8db941b1b94a8a1ce5c273b55dc94d99a171377969234134e7dad1ab4c8e46d18df4dc016764cf95a11ac4b491a2646be1
Mac = 1ba0e66cf72efc349207
My understanding is that with a key and value that openssl would get the mac, however I am not getting the same mac as that above?
echo -n "<Msg here>" | openssl sha1 -hmac "82f3b69a1bff4de15c33"
(stdin)= 981c64f70b07634e01b3800447e6431dddb42530
Any ideas on what I am doing wrong? i am also just guessing sha1, other values don't match either, I don't know how to take from the file what way I should be doing this. The various lengths, and the count. How do I use this information?
I'm not experienced with programming, and the PyCrypto documentation is pretty sparse for a beginner. Let's say that I encrypt a file with the code I have written below, and send it over the internet. What I'm concerned about is the security of the file between computers A and B. Let's assume that the computers themselves are secure and the key is transported securely. Have I implemented things correctly? Anything else I should know about? Using Python 2.7 and PyCrypto 2.6
Thank you in advance for any answer.
from Crypto.Cipher import AES
from Crypto import Random
def get_random(length):
r = Random.new().read(length)
return r
def aes_encrypt(key, file_in, file_out):
data_source = open(file_in, 'rb')
data = data_source.read()
data_source.close()
iv = get_random(AES.block_size)
cipher = AES.new(key, AES.MODE_CFB, iv)
data_encrypted = iv+cipher.encrypt(data)
file_encrypted = open(file_out, 'wb')
file_encrypted.write(data_encrypted)
file_encrypted.close()
def aes_decrypt(key, file_in, file_out):
data_source = open(file_in, 'rb')
data = data_source.read()
data_source.close()
iv = data[:AES.block_size]
data = data[AES.block_size:]
cipher = AES.new(key, AES.MODE_CFB, iv)
data_decrypted = cipher.decrypt(data)
file_decrypted = open(file_out, 'wb')
file_decrypted.write(data_decrypted)
file_decrypted.close()
#testing
key = get_random(32)
#encrypting the file on computer A
aes_encrypt(key, 'file.dat', 'file.enc')
#decrypting the file on computer B
aes_decrypt(key, 'file.enc', 'file.dat')
You are missing one of the most important considerations in implementing crypto, which is message integrity. Unfortunately just encrypting a message isn't enough to ensure it isn't tampered with, especially in the case of streaming modes like CTR, CFB, and OFB.
It looks like you are using CFB mode (MODE_CFB). The way this works is a random keystream is generated with AES, and the result is XOR-ed against the plaintext. This means that if someone flips a bit in the ciphertext, the corresponding bit will flip in the decrypted plaintext. An attacker could alter your message to mean something entirely different, and there'd be no way for you to detect it. For reference of how CFB mode (decryption) works:
If I flip the first bit of the first block of the ciphertext, it'll flip the first bit of the first block of the decrypted plaintext.
You need to either apply an HMAC or use AES-GCM mode, which will handle confidentiality and integrity together.
There are better mode choices than CFB, so if there's no strong reason for preferring it, I would recommend AES-GCM first, then AES-CTR with HMAC second.