Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Mirimir]

On 05/18/2018 08:51 AM, Mark Rousell wrote:
> On 18/05/2018 20:27, Martin wrote:
>> Hello Matthias,
>>
>> Friday, May 18, 2018, 3:40:53 PM, you wrote:
>>
>>> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just 
>>> ignore this comment.
>> And again recommandatioin for Signal. It seems to be a PR campaign -
>> but a very bad one.
> 
> Indeed, there does seem to be a recurring campaign of pro-Signal
> propaganda at every turn recently on multiple fronts. It is making me
> very, very suspicious indeed.
> 
> Those who seem to be blindly claiming that Signal is a replacement for
> email, without considering the specifics of individual users and use
> cases, are not helping security, safety, or privacy (no matter what some
> of the benefits of Signal may be).

Well, PFS _is_ an advantage.

But largely, using Signal means using smartphones.

And just about _all_ smartphones are OPSEC nightmares.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [GPGME] Repeated decrypt fails

[Randy Trinh]

On Fri, May 18, 2018 at 12:31 PM, Randy Trinh  wrote:

>
> Thanks for that! I just fixed that and now the error I get the second time
> I upload is the "NO_DATA" error (which is reasonable as it decrypts anyways
> with no data), Again the file that is obtained through the upload can still
> be decrypted via the command line just fine.
>

I identified the error! I had called "gpgme_set_engine_info" in attempt to
get gpgme working on a different device earlier and did not remove this.
For some weird reason this changed the configured engine version from
2.0.22 to 1.0.0 only after the first instance.

Thanks for all the help everyone!
Randy
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Mark Rousell]

On 18/05/2018 20:27, Martin wrote:
> Hello Matthias,
>
> Friday, May 18, 2018, 3:40:53 PM, you wrote:
>
>> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just 
>> ignore this comment.
> And again recommandatioin for Signal. It seems to be a PR campaign -
> but a very bad one.

Indeed, there does seem to be a recurring campaign of pro-Signal
propaganda at every turn recently on multiple fronts. It is making me
very, very suspicious indeed.

Those who seem to be blindly claiming that Signal is a replacement for
email, without considering the specifics of individual users and use
cases, are not helping security, safety, or privacy (no matter what some
of the benefits of Signal may be).


-- 
Mark Rousell

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Christoph Anton Mitterer]

I think heise is generally becoming more and more part of the rainbow
press in gerneral.. but their repeated fake news about crypto and weird
claims "crypto must become easy" (in the sense of: people shouldn't
need to mutually authenticate) starts to get really dangerous for the
unaware people believing their shit.

Cheers,
Chris.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Martin]

Hello Matthias,

Friday, May 18, 2018, 3:40:53 PM, you wrote:

> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just 
> ignore this comment.

And again recommandatioin for Signal. It seems to be a PR campaign -
but a very bad one.

-- 
Best regards,
Martin


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)

[Daniel Kahn Gillmor]

On Fri 2018-05-18 05:31:36 +, Fiedler Roman wrote:
> I see. If understood correctly, the trusted.gpg.d bypasses key
> management with apt-key completely, so not running into problems with
> apt-key deprecation.

I'm actually advocating avoiding trusted.gpg.d entirely as well, and
moving to explicit per-repo keyrings.

So keep trusted.gpg and trusted.gpg.d completely empty, and populate
/etc/apt/sources.list with lines like:

deb [signed-by=/usr/share/keyrings/debian-archive-keyring.gpg] 
http://ftp.debian.org/debian buster main

> I thought about that also, but shouldn't 99%+ of systems perform no
> pinning whatsoever of packages to repositories?  In that case, the
> "wrong" repository could publish just a slightly increased package
> version number of a package from another repository.

You're asking the right questions.  But please read
https://wiki.debian.org/DebianRepository/UseThirdParty#Standard_pinning
and the other sections on that page in more detail for the answers :)

> Unless my system is misconfigured or other assumptions do not hold
> true, that would imply, that the only security benefit from key
> pinning is only about maintenance, making detection/pruning of stale
> keys easier.

Another benefit is that it is a necessary prerequisite if we want to be
able to constrain some .debs (e.g. https://wiki.debian.org/UntrustedDebs
and https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging) based
on their origin.  This is still more work to be done, but if we can't
isolate repos from one another than it'll never work.  So please don't
discount this work just because we haven't achieved all the rest of the
isolation yet.

The journey of a thousand miles begins with a single step, as they say.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking MIME concatenation

[Daniel Kahn Gillmor]

On Fri 2018-05-18 13:50:00 +, Whitey wrote:
> Robert J. Hansen wrote:
>> I don't have concrete numbers here, but my suspicion is that GnuPG is a
>> package verification system that's useful for email... and most of the
>> problems people have with it as a package verification system stem from
>> the fact it was originally an email privacy system.
>
> Which might explain why some Linux distros are lax about updating GnuPG.
> Ancient versions work o.k. for package verification.

they won't be OK once the switch to ed25519 happens :/

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Robert J. Hansen]

> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just 
> ignore this comment.

He's also not exactly wrong.  The continuing support for SE packets is
an embarrassment to us.  In our defense, though, the GnuPG userbase
revolts whenever Werner mentions something as mild as dropping PGP 2.6
support.  When Patrick changed Enigmail to consider lack of MDC a fatal
error, he had five complaints overnight.

It's very easy for pundits to say "your backwards compatibility is a
real problem, you need to break it and move forwards."  But I don't see
any of them volunteering to answer all of the support requests that
would flood in if we were to do that.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Don't Panic.

[MichaelQuigley]

"Gnupg-users"  wrote on 05/15/2018 02:45:35 
PM:
> - Message from "Mark H. Wood"  on Tue, 15 May 
> 2018 11:06:26 -0400 -
> 
> To:
> 
> gnupg-users@gnupg.org
> 
> Subject:
> 
> Re: Don't Panic.
> 
> On Mon, May 14, 2018 at 04:48:31PM +0100, Mark Rousell wrote:
> > Amongst other things this includes the following paragraph which, as I
> > understand it, is essentially untrue:
> > 
> > "There are currently no reliable fixes for the vulnerability. If 
you
> > use PGP/GPG or S/MIME for very sensitive communication, you should
> > disable it in your email client for now," said Sebastian Schinzel
> > , a
> > professor of computer security at the University.
> 
> Heh.  "We've discovered that locks can be picked, so you should remove
> all the locks from your doors right now."
> 
> -- 
> Mark H. Wood
> Lead Technology Analyst

+1

Well said.

Michael Quigley
Computer Services
The Way International___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Ralph Seichter]

On 18.05.18 15:40, Matthias Mansfeld wrote:

> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just
> ignore this comment.
>
> https://heise.de/-4051354

Fortunately not everybody at Heise is clueless and/or a PGP hater:
https://heise.de/-4050153

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [GPGME] Repeated decrypt fails

[Randy Trinh]

On Fri, May 18, 2018 at 5:58 AM, Werner Koch  wrote:

>
Here you show the result of the start operation which is usuallay
success.  What you need to check here instead is STAT as returned by
gpgme_wait.


Thanks for that! I just fixed that and now the error I get the second time
I upload is the "NO_DATA" error (which is reasonable as it decrypts anyways
with no data), Again the file that is obtained through the upload can still
be decrypted via the command line just fine.

>
Is there a reason why you use the asynchronous operaions and not the
synchronous?  Your code would not work with multiple threads because
gpgme_wait may only be called by one thread.


The only reason I have it as asynchronous would be because the file that is
being decrypted is then unzipped and its contents loaded elsewhere - but
rather than using a library (as of current), I just called a system() to
execute the zip and without this.

>
gpgme has a function to figure this out:

  /* Get the information about the configured engines.  A pointer to the
   * first engine in the statically allocated linked list is returned.
   * The returned data is valid until the next gpgme_ctx_set_engine_info.
*/
  gpgme_engine_info_t gpgme_ctx_get_engine_info (gpgme_ctx_t ctx);

With this I can confirm its using 2.0.22.

>
Cheers,
Randy
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

[Matthias Mansfeld]

OK, maybe someones weekend will be spoilt after reading this comment, 
but hey, it's an original Jürgen Schmidt (responsible redactor seems 
to be Martin Holland), what else would you expect

Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just 
ignore this comment.

https://heise.de/-4051354

(in German language, I don't think it's worth a translation :-/ )

Regards
Matthias

--
Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das 
erschweren, mailen wir uns gerne mit (Open)PGP verschlüsselt.
-
Matthias Mansfeld Elektronik * Leiterplattenlayout
Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8
Internet: http://www.mansfeld-elektronik.de
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking MIME concatenation

[Whitey]

Robert J. Hansen wrote:
> I don't have concrete numbers here, but my suspicion is that GnuPG is a
> package verification system that's useful for email... and most of the
> problems people have with it as a package verification system stem from
> the fact it was originally an email privacy system.

Which might explain why some Linux distros are lax about updating GnuPG.
Ancient versions work o.k. for package verification.

-- 
Whitey

"To suppress free speech is a double wrong.  It violates the rights
 of the hearer as well as those of the speaker." Frederick Douglass

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)

[NdK]

Il 18/05/2018 07:31, Fiedler Roman ha scritto:

> I thought about that also, but shouldn't 99%+ of systems perform no pinning 
> whatsoever of packages to repositories? In that case, the "wrong" repository 
> could publish just a slightly increased package version number of a package 
> from another repository. Unattended updates will apply it anyway and also for 
> users it would be hard noticing it: at least my "apt-get" version does not 
> show any information about the repository a package would be downloaded from 
> before confirming the installation. Thus the user would have to check each 
> single package manually by invoking "apt-cache policy [pkg-name]" or use 
> "apt-get download [packagelist]", check the logs and install packages with 
> "dpkg".
Well, assume that who can publish to a repo you trust *is root* on your
machine. Even if you could pin the package, what prevents him from
adding a suid exe ?

> Unless my system is misconfigured or other assumptions do not hold true, that 
> would imply, that the only security benefit from key pinning is only about 
> maintenance, making detection/pruning of stale keys easier.
That's exactly what ther're for.

BYtE,
 Diego


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Efail or OpenPGP is safer than S/MIME

[Patrick Brunschwig]

On 17.05.18 13:03, Werner Koch wrote:
> If you parse DECRYTPION_INFO beplease consider that its current
> defineion (in master) is:
> 
> *** DECRYPTION_INFO   []
> Print information about the symmetric encryption algorithm and the
> MDC method.  This will be emitted even if the decryption fails.
> For an AEAD algorithm AEAD_ALGO is not 0.  GPGSM currently does
> not print such a status.
> 
> The important print is that MDC_METHOD will be 0 with the forthcoming
> AEAD algorithm.  Thus you need to check whether 3rd argument is there.
> 
>  mdc_method = atoi(arg_1)
>  aead_algo = have_3_args? atoi(arg_3) : 0
>  if (!mdc_method && !aeadalgo)
> return DECRYPTION_FAILED
> 
> That is what I implement in GPGME this morning.

How far back will that solution work? I.e. is this supported by all
2.0.x and 2.2.x versions of gpg?

Thanks,
Patrick


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [GPGME] Repeated decrypt fails

[Werner Koch]

On Thu, 17 May 2018 20:48, trinh.ra...@gmail.com said:

> err = gpgme_op_decrypt_start(ctx, fileEncrypted, fileDecrypted);
> ctx = gpgme_wait(ctx, , 1);
>
> std::cout << "Decrypt Status: " << gpgme_strerror(err) << std::endl;

Here you show the result of the start operation which is usuallay
success.  What you need to check here instead is STAT as returned by
gpgme_wait.

Is there a reason why you use the asynchronous operaions and not the
synchronous?  Your code would not work with multiple threads because
gpgme_wait may only be called by one thread.

> The version of GPG I am using is 2.0.22 (or 1.4.16) I have both installed

gpgme has a function to figure this out:

  /* Get the information about the configured engines.  A pointer to the
   * first engine in the statically allocated linked list is returned.
   * The returned data is valid until the next gpgme_ctx_set_engine_info.  */
  gpgme_engine_info_t gpgme_ctx_get_engine_info (gpgme_ctx_t ctx);
  
or you run your program with

  GPGME_DEBUG=1:gpgme.log: ./test

which prints the full name of the used tools.  Call them then with
option --version.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpjkJ6oO0dzR.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users