LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 05-14-2018, 07:39 AM   #1
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Rep: Reputation: Disabled
Critical PGP and S/MIME bugs


there's a post by Dan Goodin on Ars Technica this morning dealing with PGP/GPG in e/mail clients

see
Critical PGP and S/MIME bugs can reveal encrypted emails—uninstall now [Updated]

reading through the message my yellow lamp came on when they said to "use Signal instead"

there's been trouble with the program that reads the GPG passphrase and holds it ( "pinentry" ? ) -- the question being -- how long should the passphrase be held ?

One should hit the lock sequence on the keyboard before stepping away from a workstation.

I've had trouble from time to time with Thunderbird/Enigmail. This seems to be related to the use of the OpenPGP interface rather than the GPGME as used in CLAWS

CLAWS seems to be a much more stable platform; I prefer that to T-Bird although I've yet to finish converting my various receive rules.

anayway this will be an important topic to track.
 
Old 05-14-2018, 09:24 AM   #2
MensaWater
LQ Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, CoreOS, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 7,831
Blog Entries: 15

Rep: Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669
There's been a lot of chatter on the GnuPG mail list this morning suggesting the folks at EFF are causing needless panic and ultimately sent this press release:

Quote:
From: Gnupg-users [mailto:gnupg-users-bounces+jlightner=dsservices.com@gnupg.org] On Behalf Of Robert J. Hansen
Sent: Monday, May 14, 2018 8:28 AM
To: GnuPG-Users
Subject: Efail press release

Over the last few hours, Werner, Andre, and I have been working on an
official statement about the Efail paper. Without further ado, here it is.



An Official Statement on New Claimed Vulnerabilities
== ======== ========= == === ======= ===============
by the GnuPG and Gpg4Win teams

(This statement is only about the susceptibility of OpenPGP, GnuPG, and
Gpg4Win. It does not cover S/MIME.)

Recently some security researchers published a paper named "Efail:
Breaking S/MIME and OpenPGP Encryption using Exfiltration Channels".
The EFF has gone so far as to recommend immediately uninstalling
Enigmail. We have three things to say, and then we're going to show you
why we're right.

1. This paper is misnamed.

2. This attack targets buggy email clients.

3. The authors made a list of buggy email clients.

In 1999 we realized OpenPGP's symmetric cipher mode (a variant of cipher
feedback) had a weakness: in some cases an attacker could modify text.
As Werner Koch, the founder of GnuPG, put it: "[Phil Zimmermann] and Jon
Callas asked me to attend the AES conference in Rome to discuss problems
with the CFB mode which were on the horizon. That discussion was in
March 1999 and PGP and GnuPG implemented a first version [of our
countermeasure] about a month later. According to GnuPG's NEWS file,
[our countermeasure] went live in Summer 2000."

The countermeasure Werner mentions is called a Modification Detection
Code, or MDC. It's been a standard part of GnuPG for almost eighteen
years. For almost all that time, any message which does not have an MDC
attached has caused GnuPG to throw up big, clear, and obvious warning
messages. They look something like this:

gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created
2017-01-01
"Werner Koch <wk@gnupg.org>"
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 7
[GNUPG:] PLAINTEXT 62 1526109594
[GNUPG:] PLAINTEXT_LENGTH 69
There is more to life than increasing its speed.
-- Mahatma Gandhi
gpg: WARNING: message was not integrity protected
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

GnuPG also throws large warning messages if an MDC indicates a message
has been modified. In both cases, if your email client respects this
warning and does the right thing -- namely, not showing you the email --
then you are completely protected from the Efail attack, as it's just a
modern spin on something we started defending against almost twenty
years ago.

If you're worried about the Efail attack, upgrade to the latest version
of GnuPG and check with your email plugin vendor to see if they handle
MDC errors correctly. Most do.

You might be vulnerable if you're running an ancient version of GnuPG
(the 1.0 series; the current is 2.2), or if your email plugin doesn't
handle GnuPG's warning correctly. You might also have had some exposure
in the past if back then you used a pre-2000 version of GnuPG, and/or an
email plugin which didn't handle the warning correctly.

We made three statements about the Efail attack at the beginning. We're
going to repeat them here and give a little explanation. Now that we've
explained the situation, we're confident you'll concur in our judgment.

1. This paper is misnamed. It's not an attack on OpenPGP. It's an
attack on broken email clients that ignore GnuPG's warnings and do silly
things after being warned.

2. This attack targets buggy email clients. Correct use of the MDC
completely prevents this attack. GnuPG has had MDC support since the
summer of 2000.

3. The authors made a list of buggy email clients. It's worth looking
over their list of email clients (found at the very end) to see if yours
is vulnerable. But be careful, because it may not be accurate -- for
example, Mailpile says they're not vulnerable, but the paper indicates
Mailpile has some susceptibility.

The authors have done the community a good service by cataloguing buggy
email email clients. We're grateful to them for that. We do wish,
though, this thing had been handled with a little less hype. A whole
lot of people got scared, and over very little.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
 
3 members found this post helpful.
Old 05-15-2018, 07:26 AM   #3
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
the more i read about this the brighter that yellow lamp gets. the red lamp is likely to come on,-- RSN

evidently this whole "bug" depends on malicious code delivered in an HTML document. Probably using java to connect the HTML "message document" to additional remote servers -- and then using a corrupted document such as flash, or word macros|scripts, or pdf documents containing similar garbage.

the immediate question is then: what does this have to do with PGP/GPG ?

any received e/mail could contain that sort of attack code

the advantage of PGP/GPG is that -- when the message is signed -- you may have a pretty good idea who sent it ( if you're doing PGP/GPG right you do ) -- and -- that the message has not been altered en route.

if I understand PGP/MIME properly -- PGP/MIME acts as a container -- similar to .zip: when a message is "MIMED" the e/mail text and any attachments are collected and put into this pgp/mime "container". It is the container then that is encrypted and signed.

i see a lot of emphasis on encryption. and that's All Good although the AUTHENTICATION -- that comes with the SIGNATURE is likely more important. a lot of fraud -- digital or otherwise -- depends on fake identities. the whole of the key model in PGP/GPG was designed to address this problem -- in the digital environment.

this being the case then when the pgp/mime container has been decrypted the content is then presented to the HTML rendering engine. And if the rendering engine hits that malicious code fragment then that's where the trouble hits.

but this is NOT DIFFERENT from reading any ordinary HTML base e/mail.

which brings us to an important question: in what manner is e/mail being used? for protected traffic it should be used with PGP/GPG -- using encryption and signatures. yes-- you'll have to validate the keys -- but: you need to do that in this crazy world today.

any system receiving and processing e/mail inputs from the public -- should be using a CONTAINER

interestingly I've seen now another web post directing readers to "use Signal". This is what switches on the yellow light and now 2 yellow lights. is this whole bug-a-marole just a push for this signal app? Signal is fine -- but this ain't the way to promote it.

Last edited by mike acker; 05-15-2018 at 07:29 AM.
 
Old 05-15-2018, 07:42 AM   #4
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,258
Blog Entries: 3

Rep: Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713Reputation: 3713
Quote:
Originally Posted by mike acker View Post
Signal is fine -- but this ain't the way to promote it.
No. Signal is not. The EFF just decided not to promote worry or hysteria about it's bugs like it has with the not-PGP bug. There were some major holes in it during the last year that were a bigger deal than this not-PGP hole. Further, unlike e-mail (IMAPS+SMTP) the architecture of Signal is centralized and resides on servers in the US. If that is not enough, there are proprietary dependencies in part of it. Oh and I wouldn't trust most of the platforms it is marketed for, even if the baseband OS were not also an issue.

The cynic in me says to follow the money and see who is using the EFF for influence *cough*omidyar*cough* and see who turns up and what their agenda is. RIP John Perry Barlow.

But I agree, what the EFF did was not the right way to promote signal.
 
Old 05-15-2018, 08:45 AM   #5
MensaWater
LQ Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, CoreOS, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 7,831
Blog Entries: 15

Rep: Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669Reputation: 1669
Quote:
the immediate question is then: what does this have to do with PGP/GPG
That was the main point of the discussion by the GnuPG folks. They're saying the issue has all to do with badly configured MTAs but the EFF allowed the authors to post as if it is a bug in OpenPGP/GPG in their title even though the detail that follows in the post indicates it is only an issue in specific MTAs.

I do give the GnuPG folks a bit of knock though. They admit someone asked to have a call with them after they responded to an early draft but they never scheduled the call, apparently thinking the authors would.
 
Old 05-15-2018, 10:03 AM   #6
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
if I understand the process correctly: when an e/mail is signed and/or encrypted using pgp/mime: First the message text and any attachment(s) are packed into the pgp/mine container. like .zip -- this results in a single file. the pgp/mime container is then hashed and the hash is then signed using the sender's pgp secret key.

if encryption was also selected then the pgp/mine container will also be encrypted for the recipient(s) public key(s)

once this is complete the message can be sent

if the message is intercepted en route ( not very likely ) -- then -- if so much as 1 bit is changed in the pgp/mine container -- the sender's signature will fail when the recipient checks it. inserting a malicious code fragment ? maybe but it would be necessary to adjust the container such that the identical hash is developed. possible I suppose but the cost would put this well out of the realm of probable.

now if the message is encrypted but not signed then this attack might be more practical -- except for that modification blocker that was installed some time back -- what was it called ??

I can see sending a message in plain text -- but signed. but WHY would anyone send one encrypted but not signed ?????

too many good folks today focus way too much on encryption and not nearly enough on AUTHENTICATION.

Last edited by mike acker; 05-15-2018 at 10:06 AM.
 
Old 05-15-2018, 06:08 PM   #7
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by mike acker View Post
if the message is intercepted en route ( not very likely ) -- then -- if so much as 1 bit is changed in the pgp/mine container -- the sender's signature will fail when the recipient checks it. inserting a malicious code fragment ? maybe but it would be necessary to adjust the container such that the identical hash is developed. possible I suppose but the cost would put this well out of the realm of probable.
The problem is that the attacker can remove the signature completely, and then send an unsigned modified message. Now, even if you get a warning that the message is unsigned, you're email client might still decrypt and display the HTML automatically. If "display HTML" includes rendering <img> tags or similar, then it accesses URL's chosen by the attacker, meaning you've sent them all your secret data.
 
Old 05-16-2018, 04:57 AM   #8
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ntubski View Post
The problem is that the attacker can remove the signature completely, and then send an unsigned modified message. Now, even if you get a warning that the message is unsigned, you're email client might still decrypt and display the HTML automatically. If "display HTML" includes rendering <img> tags or similar, then it accesses URL's chosen by the attacker, meaning you've sent them all your secret data.
thanks--

to intercept -- and then to re-process a e/mail en-route -- is no simple task. One might think about getting some malware into an eMail server someplace.

but in this scenario -- if, as the attacker, I'm going to strip the signature -- why should i bother to intercept a message? I can easily generate a message, spoof the sender's name, and encrypt it using your public key

let's say I spoof the sender's name to be your boss' name

so now you receive an encrypted -- but unsigned message that appears to be from your boss

so far this looks like an ordinary phishing attack. ordinary folks just rushing along with the day's business may well click an infected message without giving it any further thought

this is latest gig then seems more like a new twist to an existing problem: phishing.

the real problem here leads back to what I like to describe as executable documents: documents that have program-like capabilities: macros, scripts, flash, ...

I'm interested in the container concept as possible help for this problem. I've played with Firejail a bit but I need to learn to edit the configuration file.
 
Old 05-16-2018, 06:14 AM   #9
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by mike acker View Post
to intercept -- and then to re-process a e/mail en-route -- is no simple task.
It doesn't have to be en-route, taking an old message and re-sending could also work. Which is also not necessarily easy.

Quote:
but in this scenario -- if, as the attacker, I'm going to strip the signature -- why should i bother to intercept a message?
The idea is that there is some secret data in that message that the attacker can trick your mail client into revealing.

The attacker modifies the message in such a way that when the email client decrypts and renders the HTML, the decrypted data ends up in an image URL, so that the email client sends the decrypted data to the attacker's web server. Note that you don't have to respond to the message, just read it.
 
Old 05-16-2018, 06:55 AM   #10
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ntubski View Post
It doesn't have to be en-route, taking an old message and re-sending could also work. Which is also not necessarily easy.



The idea is that there is some secret data in that message that the attacker can trick your mail client into revealing.

The attacker modifies the message in such a way that when the email client decrypts and renders the HTML, the decrypted data ends up in an image URL, so that the email client sends the decrypted data to the attacker's web server. Note that you don't have to respond to the message, just read it.
"modifies the message"

??

He's gonna have to decrypt it first and if he's got that done why bother with anything further? He'd just be risking detection unnecessarily.

this while "EFAIL" report looks a little weak to me. perhaps this is meant to deliver malware that then conducts general surveillance of the target.

Last edited by mike acker; 05-16-2018 at 06:57 AM.
 
Old 05-16-2018, 07:40 AM   #11
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by mike acker View Post
"modifies the message"

??

He's gonna have to decrypt it first
Nope.
 
Old 05-16-2018, 02:22 PM   #12
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ntubski View Post
Go ahead

Code:
-----BEGIN PGP MESSAGE-----

hQIMA2pA99svfjuqAQ//Z1i5anvYa06xSAsakaLxnIaa4aRz/hipGCIpquBEFHN7
WS2UnGyoZFGuURo7gRG7TC4dgdPcs4AGDL4R+qRdQeuHOn59UJUuhOflYnIe43QM
sqxts/u2423xQYu/B36qOQr25/ShL0PA6JzzHM6kKJkejoEHHBz7GoBGkLw5heA8
+O6YMTYSRU7vFgLjMa/YvqEX5u2JrllUekr5PAGqFYFyc82wI2U2VwJr+R737IYt
rH6rjHWa7xZQCAWPvAcWIhoZv0IeNzvcIuUtswe4nf2cZnFgkzzC9ZPWJzUP2YIk
53mz+EooPp+guF6D5FpA3jtJFaI0vJVfmcdYSAbP4+FyZ15bzyuqlXtKdmmrMrtC
iqWoeLKkiAOgaMg3xSnrn3MN1NU/jk1bow9BRUihd9H2xBEW2sWIUJ1T4WwjQCcK
RyzhxV4I9y5Zf6x/R3l+HObWO6oENTCUxA+1jKFB9DTMrq7e0O99ZgVPA8EsPQZf
27C1HsAawwqb1TPeRfb4hmHIzHISwugjJ7ucZqm11lbNFkJ7x6dDDCzlAmYg5E6i
4mMFEY93seEjCD/zW5dB16Lr39rsUZJs9AhH+q0o5RhENIKE4pPhQsm95lOPgTfM
YuIa9iWBCKAHM01GOLxKBOBw7Plq9p9IlUz5tWOR0Qmp4GKGUlDbUn5WMp4K0djS
6QF0cAuhSOOiqHf6XbyN1uUyafNqkiJkuCwaQlQLWzX8xJ0jmPRe9yH9fT/xYeqR
ve3dl5mHVL+MyRWP5B2d9ILad18Pu0GpoEc57SwY1Le9CiXwfVsH7qfc2mMCKChI
0jfgBH9Bcz0L3e42PF0GEX6L4oyKrO1ODI7K0eYX9ndswc4Up3MXETvmrpCYhZmy
SovzSmzjoWvGEJOaDNRm5H10IATV1NzH16t81W7vQhPQtSjTK83Rp1tQOBj/oI9M
hQWeGsUA+3IMlQhZ+n8Zr1iS6AkWQFTQ2Ju3/4+Rm2YnKZA9aiN+z4ZgI5sFt4+e
pyNqyMLwnca1L7RfCH+Q57rtshWtMpwex0L8SklSzHH5nWjWrSb9SmIrNjzQgRKk
uLTCp5rFyOrCu4SzzwxCfN6RIdiylsc820e+DjnBtLjMNn5qPuKAuv2Mi+FGNaTd
2SgN3M/MU+4+OVEmrMGPda5JpCyQaU8pSLRMrl4ImI8CrnWHK2j0GzC9xlPhtPYE
8gJ0E6uauHiuCIfkuJ/A80x5btozwov7cBb8OLP2xt8qG5m2VNPJ+zrAsSlWuJC/
4c6COPetbHNdUEB7tPg3xskGjTCF2Eh7e1OExyMlIPPfb8cJv5MkSZqUqLN5ESWu
uPsw3qHGmSLvyqDU2kmAfkk8h1FigzPg592w9kqXXSPfwRP9Lmb9WtdlHmggn9pS
e2NZdycO5TvI0V0pV+kJRRPff6Cu0P6T+t2MsdakChAbRHS6Uk4fpFT2M/Mh2lyz
YsCxb3W8VubUySZ0T//Xct1UavLENoPPcE4XpNQOeTMfE6eW+CWEDhoCdtqlOMxa
uSqSvg8bx6s31ZQa6VYuF2rPz2lguide2GrQZEQqoEE9wqOPFg28u4ZBQKIT1FZ4
VZRoaAHbZlirXoBAXtI00F/WlBnTIO+KEz+hkShXtl02TfapG61fF3KwQaDUuvB9
1DLs330hsvJKERiOie/zSVWaALNXodpBaSGPbGl9k06jGazv8iHjlWgQuVOC6dBY
iproFWJYSQTRUIu2wcBQiooKAM9SdA5jvbNp2oLpe7TJseF4qgLaErO/YtCgVuYa
bnDWkUqlFT5T5yWbo/JpyY5L+dW8Kb7E/PrLgLZn/m6/GEYoz7A6uKPk5vl7dWtk
DwVVkMaAHFprhfchlsY+d1N7VIthJ6yrKCYiuv2WWI/0YDiBs/qoqsbBNFW516qj
6WNIa5Nk2/TVW8HUdlbiAj4SPu8e0H1vCKU9XX0AduPJMM3WYYbaOahGesKNXy2e
UrjWbIadDD6qyHgdOy6gf22TlHC0Og==
=ed5H
-----END PGP MESSAGE-----
 
Old 05-16-2018, 04:00 PM   #13
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
if you modify the .asc -- the message won't decrypt:

like so:

~/Documents/1 Workareas/Workarea34$ gpg --decrypt Chromebook_Analysis-X.html.asc
gpg: CRC error; B109E1 - 79DE47
gpg: encrypted_mdc packet with unknown version 255

there's a pretty good explanation of what's actually going on in this -- HERE

the attack is on the e/mail program and the standard for message processing and this appears to leverage messages which are only partially encrypted/signed. if i recall -- Thunderbird issues a warning note for this condition.

I generally did like CLAWS better, anyway

Last edited by mike acker; 05-16-2018 at 04:39 PM.
 
Old 05-17-2018, 07:16 AM   #14
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by mike acker View Post
if you modify the .asc -- the message won't decrypt:
It will still decrypt if you update the CRC accordingly, and don't mangle the message too badly. It does show a warning "gpg: WARNING: encrypted message has been manipulated!", but if your mail client ignores the warning, or doesn't ignore it but still renders the HTML, then that doesn't help so much.

Now, you might object that I haven't actually changed the message. Which is true, I only modified the MDC. Changing the message to something readable it is tricky because of the compression. I don't have time to research the techniques to get around this and come up with an example, unless... could you give me a million dollars so I can quit my job and devote myself full-time to the task?


Code:
-----BEGIN PGP MESSAGE-----

hQIMA2pA99svfjuqAQ//Z1i5anvYa06xSAsakaLxnIaa4aRz/hipGCIpquBEFHN7
WS2UnGyoZFGuURo7gRG7TC4dgdPcs4AGDL4R+qRdQeuHOn59UJUuhOflYnIe43QM
sqxts/u2423xQYu/B36qOQr25/ShL0PA6JzzHM6kKJkejoEHHBz7GoBGkLw5heA8
+O6YMTYSRU7vFgLjMa/YvqEX5u2JrllUekr5PAGqFYFyc82wI2U2VwJr+R737IYt
rH6rjHWa7xZQCAWPvAcWIhoZv0IeNzvcIuUtswe4nf2cZnFgkzzC9ZPWJzUP2YIk
53mz+EooPp+guF6D5FpA3jtJFaI0vJVfmcdYSAbP4+FyZ15bzyuqlXtKdmmrMrtC
iqWoeLKkiAOgaMg3xSnrn3MN1NU/jk1bow9BRUihd9H2xBEW2sWIUJ1T4WwjQCcK
RyzhxV4I9y5Zf6x/R3l+HObWO6oENTCUxA+1jKFB9DTMrq7e0O99ZgVPA8EsPQZf
27C1HsAawwqb1TPeRfb4hmHIzHISwugjJ7ucZqm11lbNFkJ7x6dDDCzlAmYg5E6i
4mMFEY93seEjCD/zW5dB16Lr39rsUZJs9AhH+q0o5RhENIKE4pPhQsm95lOPgTfM
YuIa9iWBCKAHM01GOLxKBOBw7Plq9p9IlUz5tWOR0Qmp4GKGUlDbUn5WMp4K0djS
6QF0cAuhSOOiqHf6XbyN1uUyafNqkiJkuCwaQlQLWzX8xJ0jmPRe9yH9fT/xYeqR
ve3dl5mHVL+MyRWP5B2d9ILad18Pu0GpoEc57SwY1Le9CiXwfVsH7qfc2mMCKChI
0jfgBH9Bcz0L3e42PF0GEX6L4oyKrO1ODI7K0eYX9ndswc4Up3MXETvmrpCYhZmy
SovzSmzjoWvGEJOaDNRm5H10IATV1NzH16t81W7vQhPQtSjTK83Rp1tQOBj/oI9M
hQWeGsUA+3IMlQhZ+n8Zr1iS6AkWQFTQ2Ju3/4+Rm2YnKZA9aiN+z4ZgI5sFt4+e
pyNqyMLwnca1L7RfCH+Q57rtshWtMpwex0L8SklSzHH5nWjWrSb9SmIrNjzQgRKk
uLTCp5rFyOrCu4SzzwxCfN6RIdiylsc820e+DjnBtLjMNn5qPuKAuv2Mi+FGNaTd
2SgN3M/MU+4+OVEmrMGPda5JpCyQaU8pSLRMrl4ImI8CrnWHK2j0GzC9xlPhtPYE
8gJ0E6uauHiuCIfkuJ/A80x5btozwov7cBb8OLP2xt8qG5m2VNPJ+zrAsSlWuJC/
4c6COPetbHNdUEB7tPg3xskGjTCF2Eh7e1OExyMlIPPfb8cJv5MkSZqUqLN5ESWu
uPsw3qHGmSLvyqDU2kmAfkk8h1FigzPg592w9kqXXSPfwRP9Lmb9WtdlHmggn9pS
e2NZdycO5TvI0V0pV+kJRRPff6Cu0P6T+t2MsdakChAbRHS6Uk4fpFT2M/Mh2lyz
YsCxb3W8VubUySZ0T//Xct1UavLENoPPcE4XpNQOeTMfE6eW+CWEDhoCdtqlOMxa
uSqSvg8bx6s31ZQa6VYuF2rPz2lguide2GrQZEQqoEE9wqOPFg28u4ZBQKIT1FZ4
VZRoaAHbZlirXoBAXtI00F/WlBnTIO+KEz+hkShXtl02TfapG61fF3KwQaDUuvB9
1DLs330hsvJKERiOie/zSVWaALNXodpBaSGPbGl9k06jGazv8iHjlWgQuVOC6dBY
iproFWJYSQTRUIu2wcBQiooKAM9SdA5jvbNp2oLpe7TJseF4qgLaErO/YtCgVuYa
bnDWkUqlFT5T5yWbo/JpyY5L+dW8Kb7E/PrLgLZn/m6/GEYoz7A6uKPk5vl7dWtk
DwVVkMaAHFprhfchlsY+d1N7VIthJ6yrKCYiuv2WWI/0YDiBs/qoqsbBNFW516qj
6WNIa5Nk2/TVW8HUdlbiAj4SPu8e0H1vCKU9XX0AduPJMM3WYYbaOahGesKNXy2e
UrjWbIadDD6qyHgdOy6gf22TlHCAAA==
=FS18
-----END PGP MESSAGE-----
 
Old 05-17-2018, 07:21 PM   #15
mike acker
Member
 
Registered: Feb 2014
Location: Michigan
Distribution: Debian 10
Posts: 199

Original Poster
Rep: Reputation: Disabled
thanks for all your help on this,--

here's the result:

Quote:
$ gpg Chromebook_Analysis-XX.html.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: encrypted with 4096-bit RSA key, ID 6A40F7DB2F7E3BAA, created 2015-09-02
"Mike Acker <mike_acker@charter.net>"
gpg: WARNING: encrypted message has been manipulated!
Having read the efail.de message page -- I think I have a better understanding of this issue. as noted elsewhere I've been drifting away from T-Bird; I like CLAWS better. I think their approach is better and their program seems to run better as well.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Switch from PGP/MIME to ASCII Armor? jbiggs12 Linux - Server 1 12-20-2014 09:29 PM
S/MIME and PGP,SSL, TLS metallica1973 Linux - Security 4 08-13-2007 07:49 PM
PGP/MIME vs Clearsigning - What's the practical difference? rignes Linux - Security 4 11-12-2006 09:22 PM
Using Aegypten PGP/Mime Email in Mandrake kwalker Linux - Security 1 07-12-2004 02:38 AM
PGP/MIME for windows Ztyx General 4 09-19-2002 08:39 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 04:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration