Mengenkripsi file hanya dengan SSH -priv-key?

Misalkan saya ingin mengenkripsi file sehingga hanya saya yang bisa membacanya, dengan mengetahui kata sandi kunci pribadi SSH saya. Saya membagikan repo di mana saya ingin mengenkripsi atau mengaburkan informasi sensitif. Maksud saya, repo itu akan berisi informasi tetapi saya akan membukanya hanya dalam kasus-kasus khusus.

Misalkan saya menggunakan SSH-agent, adakah cara mudah untuk mengenkripsi file hanya dengan saya untuk membukanya nanti?
Saya tidak bisa melihat mengapa saya harus menggunakan GPG untuk ini, pertanyaan di sini ; pada dasarnya saya tahu kata sandi dan saya hanya ingin mendekripsi file dengan kata sandi yang sama dengan kunci SSH saya. Apakah ini mungkin?

ssh encryption

— Komunitas
sumber

Jawaban:

Saya pikir persyaratan Anda valid, tetapi di sisi lain juga sulit, karena Anda mencampur enkripsi simetris dan asimetris. Harap perbaiki saya jika saya salah.

Pemikiran:

Frasa sandi untuk kunci pribadi Anda adalah untuk melindungi kunci pribadi Anda dan tidak ada yang lain.
Ini mengarah pada situasi berikut: Anda ingin menggunakan kunci pribadi Anda untuk mengenkripsi sesuatu yang hanya dapat Anda dekripsi. Kunci pribadi Anda tidak dimaksudkan untuk itu, kunci publik Anda ada di sana untuk melakukan itu. Apa pun yang Anda enkripsi dengan kunci pribadi Anda dapat didekripsi dengan kunci publik Anda (penandatanganan), itu tentu bukan yang Anda inginkan. (Apa pun yang dienkripsi dengan kunci publik Anda hanya dapat didekripsi dengan kunci pribadi Anda.)
Jadi Anda perlu menggunakan kunci publik Anda untuk mengenkripsi data Anda, tetapi untuk itu, Anda tidak memerlukan kata sandi kunci pribadi Anda untuk itu. Hanya jika Anda ingin mendekripsi, Anda akan memerlukan kunci pribadi dan frasa sandi Anda.

Kesimpulan: Pada dasarnya Anda ingin menggunakan kembali frasa sandi Anda untuk enkripsi simetris. Satu-satunya program yang Anda ingin berikan passphrase Anda adalah ssh-agent dan program ini tidak melakukan enkripsi / dekripsi hanya dengan passphrase. Frasa sandi hanya ada untuk membuka kunci pribadi Anda dan kemudian dilupakan.

Rekomendasi: Gunakan openssl encatau gpg -e --symmetricdengan keyfiles yang dilindungi frasa sandi untuk enkripsi. Jika Anda perlu berbagi informasi, Anda dapat menggunakan infrastruktur publik kunci dari kedua program untuk membuat PKI / Web of Trust.

Dengan openssl, sesuatu seperti ini:

$ openssl enc -aes-256-ctr -in my.pdf -out mydata.enc

dan dekripsi sesuatu seperti

$ openssl enc -aes-256-ctr -d -in mydata.enc -out mydecrypted.pdf

Pembaruan: Penting untuk dicatat bahwa perintah openssl di atas JANGAN mencegah data dirusak. Sedikit flip sederhana dalam file enc akan menghasilkan data dekripsi yang rusak juga. Perintah di atas tidak dapat mendeteksi ini, Anda perlu memeriksa ini misalnya dengan checksum yang baik seperti SHA-256. Ada cara kriptografis untuk melakukan ini secara terpadu, ini disebut HMAC (Kode Otentikasi Pesan Berbasis Hash).

— vasquez
sumber

Anda benar bahwa kunci SSH adalah kunci asimetris, tidak cocok untuk mengenkripsi file. Dan sebagai konsekuensinya, perintah yang Anda berikan pada akhirnya tidak akan berfungsi. Anda mencoba mengenkripsi file dengan RSA, tetapi Anda hanya dapat mengenkripsi payload yang sangat kecil dengan RSA (ukuran modulus minus padding). Metode normal adalah menghasilkan kunci simetris sekali pakai, mengenkripsi itu dengan RSA, dan mengenkripsi data nyata dengan kunci simetris. Dimungkinkan untuk mengimpor kunci ssh di gpg, itu akan menjadi cara yang waras untuk menerapkan persyaratan hhh - tetapi menggunakan gpg dengan kunci gpg adalah hal yang benar untuk dilakukan.

— Gilles 'SO- berhenti bersikap jahat'

Mengapa Anda menyarankan gpg dengan -flag simetris? Ini juga berfungsi dengan "gpg -e something"tetapi untuk kasus yang berbeda?

@ hhh Saya berasumsi bahwa Anda tidak akan membagikan file Anda, jadi hanya menggunakan simetris biasa lebih aman daripada menggunakan kriptografi kunci publik. Tidak perlu untuk keypair publik / pribadi dll. Dari pgp.net/pgpnet/pgp-faq/… : "masih diyakini bahwa RSA adalah tautan terlemah dalam rantai PGP." Ini juga berlaku untuk mekanisme pubkey lainnya seperti x509.

— vasquez

Seperti apa tampilan openssl -one-liner? Sesuatu yang setara dengan $ gpg -e --symmetric?

Gunakan ini untuk mengenkripsi openssl enc -aes-256-cbc -in my.pdf -out mydata.enc:, mendekripsi dengan: openssl enc -aes-256-cbc -d -in mydata.enc -out mydecrypted.pdfkedua perintah meminta kata sandi. Lihat man enc(pada rh / fedora / centos) untuk semua opsi seperti keyfiles, base64 encoding dll.

— vasquez

Saya lebih suka menggunakan opensslutilitas karena tampaknya cukup ada di mana-mana.

Ubah kunci publik RSA dan kunci pribadi ke format PEM:

$ openssl rsa -in ~/.ssh/id_rsa -outform pem > id_rsa.pem
$ openssl rsa -in ~/.ssh/id_rsa -pubout -outform pem > id_rsa.pub.pem

Mengenkripsi file dengan kunci publik Anda:

$ openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem -in file.txt -out file.enc

Mendekripsi file dengan kunci pribadi Anda:

$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc -out file.txt

Tetapi, seperti yang dikomentari Gilles di atas, ini hanya cocok untuk mengenkripsi file yang lebih kecil dari kunci publik Anda, sehingga Anda dapat melakukan sesuatu seperti ini:

Menghasilkan kata sandi, mengenkripsi file dengan itu secara simetris, dan mengenkripsi kata sandi dengan publik Anda, kunci menyimpannya ke file:

$ openssl rand 64 | 
tee >(openssl enc -aes-256-cbc -pass stdin -in file.txt -out file.enc) |
openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem  -out file.enc.key

Dekripsi frasa sandi dengan kunci pribadi Anda dan gunakan untuk mendekripsi file:

$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc.key | 
openssl enc -aes-256-cbc -pass stdin -d -in file.enc -out file.txt

Anda akan berakhir dengan dua file, file terenkripsi dan frasa sandi terenkripsi Anda, tetapi dimasukkan ke dalam skrip yang akan berfungsi dengan baik.

Anda bahkan dapat menambahkan tar cvf file file.enc file.enc.keyuntuk merapikan.

Secara optimal, Anda akan memaksimalkan ukuran frasa sandi Anda dan juga mengubah rand 64ukuran kunci publik Anda.

— kwarrick
sumber

Dilakukan dengan sangat baik, mengingat persyaratan unik OP.

— rsaw

baru saja menemukan ini, postingan yang bagus. Saya menemukan bahwa kunci simetris ukuran maksimum yang dapat Anda hasilkan dari ssh-key adalah 12 byte lebih pendek dari ssh-key itu sendiri kalau tidak rsautl akan gagal dengan "data terlalu besar untuk ukuran kunci". Jadi ini berfungsi dalam skrip: KEYLEN_BYTES=$(ssh-keygen -l -f $PRIV_KEY | awk '{printf("%d", ($1 - 96) / 8)}')untuk autogen panjang kunci. Mengingat ssh-keygen memiliki keylength minimum 768 bit, ini masih mengarah pada kunci simetris minimum 672 bit, atau 84 byte.

— markf

Lihatlah luks / dm-crypt . Anda dapat menggunakan ssh-private-key Anda sebagai kunci enkripsi dengan menggunakan opsi yang sesuai.

Pembaruan: Contoh enkripsi menggunakan LUKS dengan perangkat LV-block (uji LV dalam sistem VG):

KEY=/home/youraccount/.ssh/id_dsa
DEVICE=/dev/system/test
cryptsetup luksFormat $DEVICE $KEY
cryptsetup luksOpen $DEVICE test_crypt --key-file $KEY

Ini seharusnya menghasilkan perangkat blok / dev / mapper / test_crypt yang dapat Anda gunakan untuk menyimpan data Anda (setelah memformatnya dengan sistem file pilihan Anda).

Untuk menghilangkannya, lakukan umount, dan gunakan cryptsetup luksClose test_crypt.

— Nils
sumber

Bisakah Anda memberi MVO agar mudah digunakan kembali?

"$ sudo apt-get install cryptmount crypt-setup; cat '...' > bin/myEncrypt.sh; chmod +x bin/myEncrypt.sh; ./bin/myEncrypt.sh; ...; ..."

Jika saya bisa mengerti dengan benar, metode ini adalah enkripsi tingkat sistem file. Ini mengenkripsi fs yang Anda butuhkan umount / mount atau saya salah membaca ini?

Saya tidak berpikir ini melakukan apa yang Anda pikirkan. The --key-filepilihan untuk cryptsetup menggunakan konten yang sebenarnya dari file sebagai satu password yang besar. Itu tidak membaca kunci openssl dari file dan hanya menggunakan itu. Anda dapat menggunakan file byte acak untuk --key-filejika Anda mau.

— Patrick

@ hhh Ya ini adalah enkripsi level-FS.

— Nils

@Nils tetapi apa yang terjadi ketika dia mengubah kata sandi pada kunci pribadinya, dia sekarang tidak akan dapat mendekripsi file-nya ketika data dalam file kunci berubah. --key-filebenar-benar nama yang dipilih dengan buruk untuk pilihan, seharusnya--password-file

— Patrick

@ Patrick Ini benar - mengubah kata sandi akan mengubah file dan dengan demikian kuncinya (dari perspektif luks). Tetapi bahkan dari sudut pandang ssh saya tidak akan menyebutkannya sebagai file kata sandi. Saya tahu bahwa jawaban saya tidak tepat sasaran - tetapi saya pikir itu akan memberikan beberapa ide.

— Nils