Chỉ mã hóa tập tin bằng SSH -priv-key?

Giả sử tôi muốn mã hóa một tệp để chỉ tôi có thể đọc được nó, bằng cách biết mật khẩu khóa riêng SSH của tôi. Tôi đang chia sẻ một repo nơi tôi muốn mã hóa hoặc làm xáo trộn thông tin nhạy cảm. Do đó, ý tôi là repo sẽ chứa thông tin nhưng tôi sẽ chỉ mở nó trong những trường hợp đặc biệt.

Giả sử tôi đang sử dụng SSH-agent, có cách nào dễ dàng để mã hóa tệp để chỉ tôi mở nó sau không?
Tôi không thể thấy lý do tại sao tôi nên sử dụng GPG cho điều này, câu hỏi ở đây ; về cơ bản tôi biết mật khẩu và tôi chỉ muốn giải mã tệp bằng cùng mật khẩu với khóa SSH của mình. Điều này có thể không?

ssh encryption

— cộng đồng
nguồn

Câu trả lời:

Tôi nghĩ rằng yêu cầu của bạn là hợp lệ, nhưng mặt khác nó cũng khó khăn, bởi vì bạn đang trộn mã hóa đối xứng và bất đối xứng. Hãy sửa lại cho tôi nếu tôi sai.

Lý do:

Cụm mật khẩu cho khóa riêng của bạn là để bảo vệ khóa riêng của bạn và không có gì khác.
Điều này dẫn đến tình huống sau: Bạn muốn sử dụng khóa riêng của mình để mã hóa thứ gì đó mà chỉ bạn mới có thể giải mã. Khóa riêng của bạn không dành cho điều đó, khóa chung của bạn ở đó để làm điều đó. Bất cứ điều gì bạn mã hóa bằng khóa riêng của bạn đều có thể được giải mã bằng khóa chung (ký), đó chắc chắn không phải là điều bạn muốn. (Bất cứ điều gì được mã hóa bằng khóa chung của bạn chỉ có thể được giải mã bằng khóa riêng của bạn.)
Vì vậy, bạn cần sử dụng khóa chung để mã hóa dữ liệu của mình, nhưng vì thế, bạn không cần mật khẩu khóa riêng cho điều đó. Chỉ khi bạn muốn giải mã nó, bạn sẽ cần khóa riêng và cụm mật khẩu.

Kết luận: Về cơ bản bạn muốn sử dụng lại cụm mật khẩu của mình để mã hóa đối xứng. Chương trình duy nhất bạn muốn cung cấp cụm mật khẩu của mình là ssh-agent và chương trình này không thực hiện mã hóa / giải mã chỉ với cụm mật khẩu. Cụm mật khẩu chỉ ở đó để mở khóa khóa riêng của bạn và sau đó bị quên.

Khuyến nghị: Sử dụng openssl enchoặc gpg -e --symmetricvới các tệp khóa được bảo vệ bằng mật khẩu để mã hóa. Nếu bạn cần chia sẻ thông tin, bạn có thể sử dụng cơ sở hạ tầng khóa công khai của cả hai chương trình để tạo PKI / Web of Trust.

Với openssl, một cái gì đó như thế này:

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

và giải mã một cái gì đó như

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

Cập nhật: Điều quan trọng cần lưu ý là các lệnh openssl ở trên KHÔNG ngăn chặn dữ liệu bị giả mạo. Một lần lật đơn giản trong tệp enc cũng sẽ dẫn đến dữ liệu được giải mã bị hỏng. Các lệnh trên không thể phát hiện ra điều này, bạn cần kiểm tra ví dụ này bằng một tổng kiểm tra tốt như SHA-256. Có nhiều cách mã hóa để thực hiện việc này theo cách tích hợp, đây được gọi là HMAC (Mã xác thực thư dựa trên Hash).

— vasquez
nguồn

Bạn đúng rằng khóa SSH là khóa bất đối xứng, không phù hợp để mã hóa tệp. Và kết quả là, các lệnh bạn cung cấp cuối cùng sẽ không hoạt động. Bạn đang cố mã hóa một tệp bằng RSA, nhưng bạn chỉ có thể mã hóa một trọng tải rất nhỏ bằng RSA (kích thước của mô-đun trừ đi phần đệm). Phương pháp thông thường là tạo khóa đối xứng sử dụng một lần, mã hóa mã đó bằng RSA và mã hóa dữ liệu thực bằng khóa đối xứng. Có thể nhập khóa ssh trong gpg, đó sẽ là cách lành mạnh để thực hiện yêu cầu của hhh - nhưng sử dụng gpg với khóa gpg là điều nên làm.

— Gilles 'SO- đừng trở nên xấu xa'

Tại sao bạn đề xuất gpg với -flag đối xứng? Nó cũng hoạt động với "gpg -e something"nhưng cho các trường hợp khác nhau?

@hhh Tôi giả sử rằng bạn sẽ không chia sẻ tệp của mình, vì vậy chỉ sử dụng đối xứng đơn giản sẽ an toàn hơn so với sử dụng mã hóa khóa công khai. Không cần cặp khóa công khai / riêng tư, v.v. Từ pgp.net/pgpnet/pgp-faq/ Khăn : "người ta vẫn tin rằng RSA là liên kết yếu nhất trong chuỗi PGP." Điều này cũng áp dụng cho các cơ chế pubkey khác như x509.

— vasquez

Các opensl -one-liner sẽ trông như thế nào? Một cái gì đó tương đương với $ gpg -e --symmetric?

Sử dụng điều này để mã hóa : openssl enc -aes-256-cbc -in my.pdf -out mydata.enc, giải mã bằng: openssl enc -aes-256-cbc -d -in mydata.enc -out mydecrypted.pdfcả hai lệnh yêu cầu mật khẩu. Xem man enc(trên rh / fedora / centos) để biết tất cả các tùy chọn như keyfiles, mã hóa base64, v.v.

— vasquez

Tôi thích sử dụng openssltiện ích này vì nó có vẻ khá phổ biến.

Chuyển đổi khóa công khai RSA và khóa riêng sang định dạng 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

Mã hóa một tệp bằng khóa công khai của bạn:

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

Giải mã tập tin bằng khóa riêng của bạn:

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

Nhưng, như Gilles đã nhận xét ở trên, điều này chỉ phù hợp để mã hóa các tệp nhỏ hơn khóa chung của bạn, vì vậy bạn có thể làm một cái gì đó như thế này:

Tạo mật khẩu, mã hóa tệp với nó một cách đối xứng và mã hóa mật khẩu với công khai của bạn, khóa lưu nó vào tệp:

$ 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

Giải mã cụm mật khẩu bằng khóa riêng của bạn và sử dụng nó để giải mã tệp:

$ 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

Bạn sẽ kết thúc với hai tệp, tệp được mã hóa và cụm mật khẩu được mã hóa của bạn, nhưng đặt vào một tập lệnh, nó sẽ hoạt động tốt.

Bạn thậm chí có thể thêm một tar cvf file file.enc file.enc.keyđể dọn dẹp.

Tối ưu, bạn sẽ tối đa hóa kích thước của cụm mật khẩu cũng như thay đổi rand 64kích thước của khóa công khai.

— kwarrick
nguồn

Được thực hiện rất độc đáo, xem xét các yêu cầu kỳ quặc của OP.

— rsaw

Chỉ tìm thấy điều này, bài viết tốt đẹp. Tôi thấy rằng khóa đối xứng kích thước tối đa bạn có thể tạo từ khóa ssh ngắn hơn 12 byte so với khóa ssh nếu không thì rsautl sẽ thất bại với "dữ liệu quá lớn so với kích thước khóa". Vì vậy, điều này đã làm việc trong một kịch bản: KEYLEN_BYTES=$(ssh-keygen -l -f $PRIV_KEY | awk '{printf("%d", ($1 - 96) / 8)}')để tự động tạo độ dài khóa. Cho ssh-keygen có độ dài khóa tối thiểu là 768 bit, điều này vẫn dẫn đến khóa đối xứng tối thiểu là 672 bit, hoặc 84 byte.

— markf

Nhìn vào luks / dm-crypt . Bạn có thể sử dụng khóa ssh-private của bạn làm khóa mã hóa bằng cách sử dụng tùy chọn thích hợp.

Cập nhật: Mã hóa ví dụ bằng LUKS với thiết bị chặn LV (kiểm tra LV trong hệ thống VG):

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

Điều này sẽ kết hợp một thiết bị khối / dev / mapper / test_crypt mà bạn có thể sử dụng để lưu trữ dữ liệu của mình (sau khi định dạng dữ liệu với hệ thống tệp bạn chọn).

Để thoát khỏi nó, hãy bỏ qua và sử dụng cryptsetup luksClose test_crypt.

— Nils
nguồn

Bạn có thể cho MVO làm điều đó để dễ sử dụng lại không?

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

Nếu tôi có thể hiểu đúng, phương pháp này là mã hóa ở cấp độ hệ thống tệp. Nó mã hóa các fs mà bạn cần umount / mount hoặc tôi đang đọc sai cái này?

Tôi không nghĩ rằng điều này làm những gì bạn nghĩ nó làm. Các --key-filetùy chọn để cryptsetup sử dụng nội dung thực tế của tập tin như một mật khẩu lớn. Nó không đọc khóa openssl ra khỏi tệp và chỉ sử dụng nó. Bạn có thể sử dụng một tệp byte ngẫu nhiên cho --key-filenếu bạn muốn.

— Patrick

@hhh Có, đây là mã hóa cấp độ FS.

— Nils

@Nils nhưng điều gì xảy ra khi anh ấy thay đổi mật khẩu trên khóa riêng của mình, giờ anh ấy sẽ không thể giải mã các tệp của mình khi dữ liệu trong tệp khóa thay đổi. --key-filethực sự là một cái tên được lựa chọn kém cho tùy chọn, nó phải là--password-file

— Patrick

@Patrick Điều này là đúng - thay đổi cụm mật khẩu sẽ thay đổi tệp và do đó là khóa (theo quan điểm của luks). Nhưng ngay cả từ quan điểm của ssh tôi sẽ không đặt tên cho nó là một tập tin mật khẩu. Tôi biết rằng câu trả lời của tôi không đạt được mục đích - nhưng tôi nghĩ nó sẽ cung cấp một số ý tưởng.

— Nils