OpenSSL có thể giải mã dữ liệu base64 không chứa ngắt dòng không?


9

Tôi có hai khối dữ liệu base64 trong một biến bash. Các ngắt dòng thông thường trong dữ liệu base64 đã được thay thế bằng khoảng trắng và biến về cơ bản là một chuỗi một dòng rất dài.

Tôi có thể giải mã hai khối dữ liệu base64 có trong biến nhưng tôi đã trải nghiệm một số sắc thái khi cố gắng thực hiện. Tôi muốn hiểu nếu tôi đang tiếp cận điều này một cách chính xác hoặc có cách nào tốt hơn để giải mã dữ liệu cơ sở64 không chứa ngắt dòng. Đây là những gì tôi có:

Đoạn đầu tiên là 350 ký tự và tôi có thể giải mã thành công như thế này:

echo ${DATA::350} | openssl base64 -d | wc -c
256

Đoạn thứ hai là 5745 ký tự nhưng lệnh trên không tạo ra kết quả như mong đợi. I E:

$ echo {DATA:350} | openssl base64 -d | wc -c
432

Tuy nhiên, nó hoạt động nếu tôi đặt dòng ngắt trở lại:

$ echo ${DATA:350} | tr ' ' "\n" | openssl base64 -d | wc -c
4240

Tôi hy vọng có một số vấn đề về độ dài dòng mà đoạn đầu tiên đủ nhỏ để tránh và nó dường như là một tính năng của bộ giải mã base64 đang được sử dụng (hai cái thông thường base64openssl base64hoạt động khác nhau).

Bộ base64giải mã (thay vì openssl base64) dừng ở ký tự không hợp lệ đầu tiên (khoảng trắng) và do đó chỉ giải mã "dòng" đầu tiên (48 byte dữ liệu đầu ra) trong khi OpenSSL tạo ra 432 ký tự (9 "dòng"). Các base64lệnh có một tùy chọn để bỏ qua rác , vì vậy công trình này:

$ echo ${DATA:350} | base64 -d -i | wc -c
4240

Bộ giải mã OpenSSL dường như không có tùy chọn như vậy.

Ngoài ra, loại bỏ khoảng trắng hoàn toàn hoạt động cho base64nhưng không openssl base64:

$ echo ${DATA:350} | tr -d ' ' | openssl base64 -d | wc -c
400

$ echo ${DATA:350} | tr -d ' ' | base64 -d | wc -c
4240

Vì vậy, cuối cùng, tôi đã thay thế các dòng mới và sử dụng bộ giải mã OpenSSL bởi vì tôi cần xử lý thêm dữ liệu được giải mã bằng mọi cách:

$ openssl enc -d -a -in <(echo ${DATA:350} | /usr/bin/tr ' ' "\n") -aes-256-cbc -pass file:<(echo $skey) | ...

Nhưng tôi muốn hiểu OpenSSL có thể giải mã dữ liệu base64 không chứa ngắt dòng không?


Bash FWIW có thể tự thay đổi hoặc xóa ký tự mà không cần trsử dụng ${var//old[/new}- nhưng không đồng thời với lớp nền.
dave_thndry_085

Câu trả lời:


17

Nếu bạn không cần khoảng trắng thì opensslsẽ xử lý việc này với -Atùy chọn:

Vì thế:

$ ls -l sp2.bmp
-rw-r--r-- 1 sweh sweh 3000054 Apr 21 20:13 sp2.bmp
$ x=$(openssl base64 -A < sp2.bmp)                
$ echo "$x" | wc
      1       1 4000073
$ echo "$x" | openssl base64 -d -A > res
$ ls -l res
-rw-r--r-- 1 sweh sweh 3000054 Jul 30 10:00 res
$ cmp res sp2.bmp 
$ 

Chúng ta có thể thấy dữ liệu base64 là tất cả trên một dòng và có thể được giải mã.

man encgiải thích các -Atùy chọn.

Nếu bạn cần giữ khoảng trắng thì bạn sẽ cần xóa chúng (bằng cách chuyển đổi sang '\n'hoặc bằng cách xóa và sử dụng -A).


Các -Atùy chọn là một trong những điều đầu tiên tôi đã cố gắng, nhưng tôi đã làm như vậy trước khi cố gắng để loại bỏ các khoảng trống và sau đó "chuyển" khi nó không làm việc! Trang người đàn ông không đề cập bất cứ điều gì về không gian là một vấn đề. Dù sao, tôi vừa thử lại lần nữa với các khoảng trắng bị xóa và nó vẫn hoạt động. Nó vẫn khó chịu nhưng ít nhất nó chỉ là một tr -d ' '. Thật xấu hổ vì nó không thể xử lý nó và bỏ qua khoảng trắng (như base64có thể).
starfry

2
RFC 4648 nói rằng các không gian nói đúng (phần 3.3) và nguồn cấp dữ liệu (phần 3.1) bị cấm trong cơ sở64. Mục 3.3 cũng cho biết việc triển khai PHẢI từ chối dữ liệu trong trường hợp này. Vì vậy, openssl base64 -Agần hơn là một giải thích nghiêm ngặt, mà bạn mong đợi từ một công cụ mã hóa bảo mật. Tôi đoán rằng coreutils base64là khoan dung hơn.
Stephen Harris

2
OpenSSL đã triển khai Base64 vào những năm 1990 (trước 4648 hoặc thậm chí 3548) chủ yếu để đọc và viết các tệp 'PEM' (thực sự giống PEM) và S / MIME, cả hai đều yêu cầu ngắt dòng. -Avề cơ bản là "chúng tôi có các EVP_{En,De}codeBlockyếu tố, cũng có thể cho phép mọi người sử dụng chúng".
dave_thndry_085
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.