Mengapa GPG tidak menyukai pesan terenkripsi ini?


2

Saya memiliki pesan terenkripsi berikut yang tergeletak di komputer saya dari belakang ketika saya bermain-main dengan GPG (dan dalam hal ini, Enigmail)

-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-15
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

.............+AWJjL0Un8xWK0lFgw26Oos
ynzsVjy9fZAVlzoVN3XgucjIG8guTrakLbbvF0aMwDIwUXb3x1b+4hGNmkx+TUQV
kE6WcnnJw5B+8/m3CQ+IxbalHKAOu7VRHZ7XJCvY6dLAIQGSmwx77S3TV4zKH5PR
p3e15GJbcM+Gfo9Ka8u6KtGZALEk9xsZjH3QmfyB66dARp4/u7gJZrJ9hd5bzXJ9
LfjEvqygdpTeak2etz+r90WbiC/P4mnXQoxz7s3m1nJESb6VcpipJFkfwFdl1BYx
0XVfY/uH/gkQGiPNQL.....................O87w==
=Cnbj
-----END PGP MESSAGE-----

Jika saya mencoba lari gpg --list-packets atau gpg --decrypt pada pesan, saya mendapatkan output berikut (dengan peringatan "karakter tidak valid dilewati" diulang sekitar tiga puluh kali):

gpg: invalid radix64 character 2E skipped
gpg: invalid radix64 character 2E skipped
gpg: invalid radix64 character 2E skipped
gpg: invalid radix64 character 2E skipped
gpg: CRC error; A3E958 - 0A76E3
gpg: [don't know]: invalid packet (ctb=3a)

Mengapa GPG tidak menyukai pesan ini? Apa yang salah dengan itu?

Jawaban:


3

Pesan OpenPGP-lapis baja ASCII diwakili dalam Radix-64 (variasi Base64 dengan checksum ditambahkan) , yang tidak memiliki simbol titik ., jadi jelas datanya rusak.

Berdasarkan pengulangan berurutan dari karakter yang sama, kemungkinan pesan tersebut sengaja diedit untuk mengaburkannya.


@ jens-erat terima kasih untuk hasil editnya, saya rasa masih banyak yang harus saya pelajari :)
JohnKiller

----- BEGIN PGP MESSAGE ----- Versi: OpenPGP.js v2.5.13 Komentar: openpgpjs.org , ini masalahnya, hapus saja dan semua akan bekerja.
waza123

0

Pesan kesalahan ini dapat disebabkan oleh jeda baris tambahan yang ditambahkan ke pesan setelah dienkripsi. Saya mendapat pesan kesalahan serupa untuk penyebab ini.

Untuk menghindari masalah ini untuk kombinasi mailvelope dan gmail / Google Inbox, enkripsi pesan sebagai file dan lampirkan file. Tampaknya masuk akal bahwa ini adalah solusi untuk skenario lain.

Ini blog memberikan penjelasan yang lebih mendalam.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.