Re: Pinentry problem with different home dir

[Steffen Nurpmeso]

Werner Koch via Gnupg-users wrote in
 <87r0lhzxgu@jacob.g10code.de>:
 |On Wed, 25 Oct 2023 18:51, Michael Richardson said:
 ...
 |Use a different home directory.  Actually running
 |  gpg --homedir /somewhere -s something
 |should be enough but the agent and dirmngr started on the fly won't be
 |killed until you rmdir /somewhere.

It would really be nice if one would be able to avoid those extras
for simple operations.  It is one reason why i still use 1.4.23,
all those surroundings that i really do not need (unless i would
need them), and that get auto-started and are then laying around.

Other than that it justs works here, with three different
homedir's (pgp with "mutilated" non-exportable etc. private key --
thanks again for this non-standard but super user helpful
possibility!, pgp-nosecrets with only the public key for
encryption, and then the usually non-available full thing.
Works for years without any issues at all.

 |Or just use -u to select a different signing key.  For example in
 |~/.gitconfig
 ...
 |[user]
 |  name = "Werner Koch"
 |  email = "w...@gnupg.org"
 |  signingkey = C1D34B69219E4AEEC0BA1C21E3FDFF218E45B72B

I did not know it even works with quotes.  Never used quotes here.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: OT: DKIM signatures on email messages from lists.gnupg.org

[Steffen Nurpmeso]

Alessandro Vesely wrote in
 <8fe44a06-cb26-db9b-bf9a-8251baf56...@tana.it>:
 ...
 |d= is not aligned.  Really, you gain nothing by removing DKIM-Signature:\
 |'s, 
 |except saving a few bytes.

Most non-spam non-patch messages i see have an exorbitant text /
header data relation.  I could not tell names now (i use

  headerpick save ignore '^Delivered-To$' '^Envelope-To$' '^Original-.*$' 
'^X-.*$' '^ARC-.+$' '^Authentication-Results$' '^DKIM.+$' ^X- ^IronPort ^MGA 
^Spam '^(Accept|Content)-Language' ^Thread-

) but there exist universities and organizations with baffling
internal email infrastructures, and each of those hops performs
spam checks, DKIM+ verification, and -signing.  Over, and over,
and over again.  (Where i would then, likely, use a (WireGuard)
VPN, or plain TLS with client certificates, to do the internal
hops.  But, you know, there is wiiind, there is sooollarrr, and
for now there are plenty nuclear plants, too.  Just my one cent.)

  ...
 |The Sender: field was considered in Microsoft's Sender ID (RFC 4405), \
 |which has 
 |been competing with SPF for some time in the past.  Every now and then \
 |someone 
 |proposes that DMARC should consider it too[*].  A receiver cannot verify \
 |that a 
 |self-appointed Sender is authorized to send messages on behalf of a \
 |bank or 
 |whoever it tries to impersonate.

The very much appreciated Dave Crocker who is in email for i think
45 years or more added RFC 9057 Author:, which is worth reading
when talking this topic.
Unfortunately the get-the-job-done-for-money people who caused all
the mess do not seem to care for it.  They do not care for the
email infrastructure at all, which finally (for me) brings back
the claims of the nonseriousity of email.
Maybe an interesting further data point i have read today in an
Austrian magazine that EU wants to have access to Signal and other
messengers aka decryption possibilities ([1], says it abstracts
[2]).


  [1] 
https://www.derstandard.at/story/300174315/eu-staaten-beharren-mehrheitlich-auf-anlassloser-messenger-ueberwachung
  [2] 
https://netzpolitik.org/2023/staendige-vertreter-eu-staaten-wollen-chatkontrolle-trotz-warnung-ihrer-juristen/#netzpolitik-pw

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: OT: DKIM signatures on email messages from lists.gnupg.org

[Steffen Nurpmeso]

Alexander Leidinger wrote in
 <20230613091839.horde.xomd2-klk1ptncda-lgs...@webmail.leidinger.net>:
 |Quoting Steffen Nurpmeso  (from Mon, 12 Jun 2023  
 |21:54:45 +0200):
 ...
 |> non-deleted things from there (also automatically).  I am happy
 |> that many lists i am on continue to use that subject tagging, or
 |> reintroduced it, because i get a human-compatible overview with
 |> a single glance (already thread-sorted) when i look into my INBOX.
 |> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
 |> more.
 |> (Having said that lists i read like those from NetBSD never did
 |> anything such, and did not need to change anything to work in
 |> today's email world.)
 |
 |As you are also on the FreeBSD mailinglists:
 |We had footers in there in the past (a quick check of messages from  
 |1999 and 2006 confirms this). In 2021 (around June/July it seems) we  
 |changed that, at least partly due to DKIM signatures failing (not sure  
 |if this was the only reason).
 |
 |I do not remember any complains from users about this change (I'm not  
 |part of the FreeBSD postmaster team, but I had a discussion about  
 |failing DKIM signatures with them, and we get internal status reports  
 |from them from time to time). We never had subject munging in place.
 |
 |With more than 100 public lists FreeBSD uses, and a lot of subscribers  
 |per list, I would say generally we can live without mail-munging by  
 |mailinglists. Those people which want to keep it the old way, are  

Yeah that is your own biased opinion, but i am happy that i am on
MLs which do otherwise.

 |typically old and experienced enough (procmail/formail anyone?) to do  
 |their own mail-munging based upon existing header lines.

You surely miss the one from the tmux developer which i never used
but would claim is surely a good one.

But it is not that simple, @FreeBSD.org developer email addresses
are often aliases to for example @gmail.com, and until at least
once i last had comm with one mails were simply retransmitted,
i had to weaken my SPF record from -all to ~all because that
failed.  (I included postsrsd in the list due to this.)

 |I also consider things like DKIM much more useful than a footer or  
 |other mail-munging.

But where is the connection with this.
It is not DKIM that kills mailing-lists, no?
Sure DKIM is something useful, unfortunately its further
development is blocked by some destroyers on the according IETF
list, it even switched to moderated mode due to that, very, _very_
ugly.  Then again i personally think DKIM and all the other things
are only plastering over a false solution, but yes, they do that.
And with PGP you can even have non-MIME confidentiality and/or
assurance (easily).  Even those who work on email for over fourty
years are having long notation threads over whether a ML sent mail
is "new", or whatever and all that .. is surely off-topic.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: OT: DKIM signatures on email messages from lists.gnupg.org

[Steffen Nurpmeso]

Konstantin Ryabitsev wrote in
 <20230612-rename-satirical-b8339e@meerkat>:
 |On Mon, Jun 12, 2023 at 09:54:45PM +0200, Steffen Nurpmeso wrote:
 |>|No it isn't. Changing the subject and adding the footer is a damaging
 |>|anti-pattern from mid-nineties. If the end-user wants to filter mail, \
 |>|they can
 |>|do it based on the List-Id header or any other criteria. Lists that \
 |>|still do
 |>|this in 2023 need to be updated to no longer do this.
 |> 
 |> That is your own biased thing to which i am totally opposed to.
 |
 |It's not "my own biased thing" -- I speak from experience of managing \
 |hundreds
 |of Linux mailing lists.

Well then, hi ho silver.
IETF has a lot of lists, too.

 |> The traditional email way uses a single INBOX and dispatches
 |> non-deleted things from there (also automatically).  I am happy
 |> that many lists i am on continue to use that subject tagging, or
 |> reintroduced it, because i get a human-compatible overview with
 |> a single glance (already thread-sorted) when i look into my INBOX.
 |> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
 |> more.
 |
 |The "traditional email way" is gone. Anyone who insists on doing things the
 |way it used to be done in the 90s is doing everyone a disservice because
 |messages sent by their users will increasingly end up in spam or be \
 |rejected
 |outright. You're contributing to the notion that email is too unreliable \
 |to be
 |used for anything serious, especially via mailing lists.

Nah, total rubbish.  As if i would count, for one.
Second, you give an interesting picture of the mental context of
the (tens of) thousands of Linux programmers you live in.

Third, S/MIME and PGP are used seriously, it is the usual maybe
western-world specific paranoia bullshit propaganda which hammers
and bastardizingly bends somewhere, also here.  Hundreds or
thousands of years you put envelope in envelope and then seal that
further.  Just put pseudo headers in the outermost and make
software use the real ones from the inside instead; that is solved
for long, except for the certificate infrastructure which
unfortunately has to be a commercial mess instead of being open
for everyone easily.  So that not.  You need some tags in the
outermost header, and DKIM is a good thing, actually.

  Having said that, the software i maintain myself cannot (until
  the MIME machinery is replaced), but i have few spare time (i
  could hack it in somewhat fast, but it would be a terrible hack
  on a terrible infrastructure) -- the question is solely why the
  big ones and their beautiful graphical programs fail to do it
  properly.  Why so.

Fourth; most spam i see comes from GMail or Outlook.
And then they killed mailing-lists ... not.  That is wonderful.
But i grant a real, proper mailing-list must sooner or later
switch to use DKIM and ARC (and/or postsrsd), and as of today
likely (dependent on its audience) needs to rewrite From: to that
'Xy via Z' in order to make it happen.  That is basically it, and
you can get away with a subject tag and a footer.
DMARC is a foul name.

Fifth email is more fifty than thirty, and i think for a reason.
Shove the rest (up your ass)!
So whereas "die Antwort heißt immer Verzicht" / "the answer is
always renunciation", that is surely not true for reliabiliy and
email.  That is a super robust forgiving thing, given that even
DMARC and that mess did not break it down.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: OT: DKIM signatures on email messages from lists.gnupg.org

[Steffen Nurpmeso]

Konstantin Ryabitsev wrote in
 <20230612-landline-jawless-f2c113@meerkat>:
 |On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-us\
 |ers wrote:
 |>> What the list-software would need to do is to strip the original \
 |>> DKIM signature
 |> 
 |> Why?  Original signatures can often be recovered.  They shouldn't \
 |> be removed
 |> anyway.
 |
 |If list-software is doing something to make the DKIM signature no longer
 |verify, it must remove the DKIM signature or rewrite the From: header to
 |change alignment.

My Mailman2 has "REMOVE_DKIM_HEADERS = 2".
(But this will change, somewhen.)

 |>> or to not modify the message (at least not the designated header lines,
 |>> and the body). More info here:
 |> 
 |> 
 |> Omitting subject tag and footer seems to me to be worse than From: \
 |> munging.
 |
 |No it isn't. Changing the subject and adding the footer is a damaging
 |anti-pattern from mid-nineties. If the end-user wants to filter mail, \
 |they can
 |do it based on the List-Id header or any other criteria. Lists that \
 |still do
 |this in 2023 need to be updated to no longer do this.

That is your own biased thing to which i am totally opposed to.
The traditional email way uses a single INBOX and dispatches
non-deleted things from there (also automatically).  I am happy
that many lists i am on continue to use that subject tagging, or
reintroduced it, because i get a human-compatible overview with
a single glance (already thread-sorted) when i look into my INBOX.
This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
more.
(Having said that lists i read like those from NetBSD never did
anything such, and did not need to change anything to work in
today's email world.)

 |> I'd definitely recommend ARC, not the conceptual Mailman 3 version.
 |> However, most receivers are not yet prepared to accept it.
 |
 |ARC is just adding more things to the chain that you must explicitly trust.
 |It's basically an assurance from the remailer that "oh, btw, I checked this
 |message and its DKIM was good, trust me." It's useful for the huge mail
 |providers like Yahoo/Gmail/Outlook, but standing up your own ARC-signing
 |infrastructure is largely just wasting cycles.

If you do DKIM then ARC does make sense.  (I am a bit away from
the standards though.)  SPF/DKIM/ARC are maybe a thing, especially
when being holistic; dmarc destroyed email (not), it should imho
be boycotted.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: expiration date for the keys pgp (automatism)

[Steffen Nurpmeso]

P.P.S.: .. and getting off-topic ..

Leonardo Taccari posted a brilliant idea to the already closed
nawk issue that should not be concealed, to which i just now
responded

--- Forwarded from Steffen Nurpmeso  ---
 |Hello!
 |
 |Leonardo Taccari wrote in
 | :
 ||@sdaoden another possible way - that should work on all the AWKs - is:
 ||
 ||```awk
 ||BEGIN { srand(); t = srand(); print t }
 ||```
 ||
 ||When `srand()` is called without any argument it will start from the \
 ||current time of day.
 |
 |That is actually a brilliant idea!
 |This works back to System V8 awk, and for BSD i am a bit out of
 |ideas, CSRG repo shows nothing before 1994, though gawk came in
 |earlier already.
 |But anyway, for (at least) almost thirty years anywhere!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: expiration date for the keys pgp (automatism)

[Steffen Nurpmeso]

P.S.:

Steffen Nurpmeso wrote in
 <20230609132434.xs7mr%stef...@sdaoden.eu>:
 |Werner Koch wrote in
 | <875y7wvn4y@wheatstone.g10code.de>:
 ||On Mon,  5 Jun 2023 14:49, broussard marc said:
 ||
 ||> => does pgp can tell when the key is becoming soon expired?
 ||
 ||That is easy on Unix:
 ||
 ||  $ gpg --list-keys --with-colons \
 ||| awk -F: -v days=60 \
 ||  'BEGIN { from=systime(); to=from+(days*86400)};\
 |
 |Not _that_ easy ("date +%s" maybe, strftime(3) %s is old).
 |
 |  #?2|kent:$ awk 'END{print systime()}' https://github.com/onetrueawk/awk.git

 |  #?2|kent:$ busybox.static awk 'END{print systime()}'  from && $7 < to { found=1 };
 ||   $1=="fpr" && found {found=0; \
 ||  print "key " $10 " expires in the next " days " days"}'
 ||
 ||A really proper solution would use a function to decode field 7 because
 ||it may in the future be shown as MMDDTHHMMSS (actually gpgsm does it
 ||this way).
 ||
 ||I will consider to allow the expiration date for the --list-filter which
 ||could then be used on Windows (i.e. w/o awk) as well.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: expiration date for the keys pgp (automatism)

[Steffen Nurpmeso]

Werner Koch wrote in
 <875y7wvn4y@wheatstone.g10code.de>:
 |On Mon,  5 Jun 2023 14:49, broussard marc said:
 |
 |> => does pgp can tell when the key is becoming soon expired?
 |
 |That is easy on Unix:
 |
 |  $ gpg --list-keys --with-colons \
 || awk -F: -v days=60 \
 |  'BEGIN { from=systime(); to=from+(days*86400)};\

Not _that_ easy ("date +%s" maybe, strftime(3) %s is old).

  #?2|kent:$ awk 'END{print systime()}'  from && $7 < to { found=1 };
 |   $1=="fpr" && found {found=0; \
 |  print "key " $10 " expires in the next " days " days"}'
 |
 |A really proper solution would use a function to decode field 7 because
 |it may in the future be shown as MMDDTHHMMSS (actually gpgsm does it
 |this way).
 |
 |I will consider to allow the expiration date for the --list-filter which
 |could then be used on Windows (i.e. w/o awk) as well.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: ADK's (was: [Announce] GnuPG 2.4.1 released)

[Steffen Nurpmeso]

gnupg-users@gnupg.org wrote in
 <20230428230349.429d3d3a@localhost>:
 |Johan Wevers via Gnupg-users  wrote:
 |>On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote:
 |>
 |>>   * gpg: New command --quick-add-adsk and other ADSK features.
 |>> [T6395, https://gnupg.org/blog/20230321-adsk.html]  
 |>
 |>So you finally caved in to the backdoor demands.
 |
 |If there is no option as you say, i would say yes.
 |
 |>What I'm missing (maybe I just didn't found it?) is an option in my
 |>config file to ignore adk requests and just don't encrypt to those keys
 |>as well when I send or reply a message.
 |
 |ACK, absolutely necessary. Otherwise GnuPG would no longer be a
 |trustworthy encryption solution.

And Patrice Lumumba was thrown into a pit of slaked lime.
(After being beaten to death with rifle butts on the flight from
western to eastern Kongo, as far as i know.  But wild times still
under colonial money mighty.  (Afaik.))

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

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

Re: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Steffen Nurpmeso]

Tony Lee wrote in
 :
 |On Aug 27 I submitted a query to this mailing list on the same Subject 
 ...
 |The concept that no thought may be given within gpg to the protection of 
 |passwords, and that deprecated cryptographic functions may be in use 
 |(despite commands to the contrary), seems to me to be highly disturbing.

Highly disturbing to me are such poisoning emails like you write
continuously.  The software you talk about is classified to be
used by governments to some extend, and i rather have Werner and
his team work on improving this big software suite than answering
mails of stinking piles.
Just my one cent.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: [Announce] A New Future for GnuPG

[Steffen Nurpmeso]

Robert J. Hansen wrote in
 :
 |Werner, this is amazing news.  Thank you for sharing it!
 |
 |For the list: as you may remember, each Christmas I run a fundraiser for 
 |GnuPG.  You pledge $X and I match it, that sort of thing.  I didn't do 
 |one this year because Werner contacted me earlier asking me not to, 
 |saying he would soon have news that would put GnuPG on much more solid 
 |financial footing.  I'm happy the news is finally ready for sharing.  :)

Congratulations also from me.
It is nothing but a shame that major projects that are used by
billion dollar companies or state agencies have to struggle for
"peanuts" (a famous term in Germany since about hm 25 years),
whereas commercial shit products shall this term be allowed
here generate unbelievable value.  ('Assuming that state has not
changed also in the software industry, which i bet on.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: Follow-up on L'Affaire Stallman

[Steffen Nurpmeso]

This is solely my opinion.  But i have to say it now.

Robert J. Hansen wrote in
 <3e47e65a-790f-e323-7a0c-c14660cd2...@sixdemonbag.org>:
 |A few weeks have passed, and I figured a recap might be appropriate:
 |
 | * FSF continues to support RMS

I have no opinion on that.  I do not know him, nor whatever.
I saw some code from him twenty years ago and did not like it :)
However, i did say in the past that i would allow him to travel by
airplane, if it would be me, which is much more than i allow
myself.  And i stand to this opinion.

 | * FSFE has ended collaboration with FSF and GNU ("we see
 |   ourselves unable to collaborate both with the FSF and any
 |   other organisation in which Richard Stallman has a
 |   leading position")

The thing is that we live in a bigot world as gods and destroy
live without just any respect.  Most humans are very small minded
and go for "each cheap piece of meat" just "to sneak away with
it".  Really, i am bored, thus.  Sigh.  Anyhow.  In the western
world cruelty and abuse and anti-social behaviour rather has
become the norm, but everywhere you find that elder suppress the
younger.  Even more so if you _see_.

So to tear open the indolence and coldness with which especially
solvent white (but not only white) people perch upon exploitation
of all possible kinds, environment, finite resources, literally
billions of livestock, child and other sexual abuse can only be
a good thing.  The living conditions that our/the tremendous
military and economic terror generates.  All this nothing but
a shame, that hole is too dark and deep, yet it exists.

Quite the opposite, who does risk a saturated and comfortable life
in order to aid for something better, at times is called a hero.
Well i would not go that far here, Mr. Stallman is from or
directly descends from a generation which actually had a quite
good outcome of people who tried to make the white race better.
Unfortunately, without success. :(

Anyhow.  There are too many narrow-minded individuals who (due to
whatever shortcoming) are not capable to put things in the actual
context of actual life as it really is (imho).

 | * GnuPG has clarified it's not part of GNU

Always has, hasn't it.  I look at that for hm a long time, and it
always was like that.

Thank you.  And have a nice day.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: Which keyserver

[Steffen Nurpmeso]

Stefan Claas wrote in
 <20200919201736.2...@300baud.de>:
 |Robert J. Hansen wrote:
 |>> It is true the attacks were what brought it down, but the amount \
 |>> of effort was not a "sustained
 |>> attack" by any measure. The invested resources are somewhere around \
 |>> "couple hours and $0.00".
 |> 
 |> I'm not sure that's true.
 |
 |[...]
 |
 |I think it does not matter.
 |
 |Professional businesses and their customers can use the mentioned Mailve\
 |lope key server,
 |to protect their keys or use for anonymity purposes Hagrid, in combination \
 |with sequoia
 |pgp, while the geeks can use WKD.
 |
 |The only thing SKS, so it seems, is currently good for is decentralized \
 |file sharing or
 |for chat purposes, when using SKS chat software.

SKS served me very well for many years, and it is a shame that
even national/related agencies with quite some funding, or
universities with that immense pool of students did not stood up
trying to keep this decade old community driven infrastructure
alive.  I guess they all were eating burger, and at that level.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
<20200530145210.ewnne%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 |<20200529202134.6lzbj%stef...@sdaoden.eu>:
 ||Steffen Nurpmeso wrote in
 ||<20200529155411.tgyu1%stef...@sdaoden.eu>:
 |||Werner Koch wrote in
 |||<87sgfjrqf1@wheatstone.g10code.de>:
 On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 | ...
 ||So with the attached patch libgcrypt solely relies upon getentropy

I realized i am in fact subscribed to -devel and moved this over.
Thank you, and Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
<20200529202134.6lzbj%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 |<20200529155411.tgyu1%stef...@sdaoden.eu>:
 ||Werner Koch wrote in
 ||<87sgfjrqf1@wheatstone.g10code.de>:
 |||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 ...
 |So with the attached patch libgcrypt solely relies upon getentropy
 |if available, no FD handling is done no more if at all possible.
 |The test suite passes, a short review makes me think it is alright.

Maybe, but it was not.
Please find attached a second one to be applied on top, it fixes
some preprocessor problems.

Please just feel free to take those, and commit under your name or
any way you like it.  Joining them into one would be nice...

Thank you, and Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
commit 5761c3fb (HEAD -> refs/heads/me)
Author: Steffen Nurpmeso 
AuthorDate: 2020-05-30 16:33:34 +0200
Commit: Steffen Nurpmeso 
CommitDate: 2020-05-30 16:44:53 +0200

Tweak previous..

- Fix preprocessor statement in #include block, it missed a && in
  between two conditions.

- Drop usage of direct syscall in _gcry_rndlinux_setup(): it used
  GRND_NONBLOCK, but that in turn needs sys/random.h which is not
  tested by the configuration.

  And GRND_NONBLOCK was defined in include/uapi/linux/random.h
  once the syscall had been introduced.  And whereas the value
  always has been 0x1, it seems better to simplify the code
  regardless of the possible bad side effect of blocking the
  program.

  (As stated on the gnupg-users ML OpenBSD i think never blocks,
  and newer Linux, i think 5.6, block in-kernel on boot until
  entropy is set free, and for older kernels it is likely that
  people use haveged or another kind of entropy booster, and/or
  ensure to restore entropy via the RNDADDENTROP ioctl(2).
  This because boot hangs became a problem several years ago.)

- Please let me use my #ifdef instead of #if.
---
 random/rndlinux.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/random/rndlinux.c b/random/rndlinux.c
index c710d368..eff5a505 100644
--- a/random/rndlinux.c
+++ b/random/rndlinux.c
@@ -32,13 +32,11 @@
 #include 
 #include 
 
-#undef HAVE_GETRANDOM_SYSCALL
-#if !defined(HAVE_GETENTROPY)
-# if defined(__linux__) defined(HAVE_SYSCALL)
+#ifndef HAVE_GETENTROPY
+# if defined(__linux__) && defined(HAVE_SYSCALL)
 #  include 
 #  ifdef __NR_getrandom
 #   define HAVE_GETENTROPY
-#   define HAVE_GETRANDOM_SYSCALL
 #   define getentropy(buf,buflen) syscall (__NR_getrandom, buf, buflen, 0)
 #  endif
 # endif
@@ -115,7 +113,7 @@ _gcry_rndlinux_setup (void)
 {
   int rv = 0;
 
-#if HAVE_GETENTROPY
+#ifdef HAVE_GETENTROPY
   if (!a_rndlinux_have_getentropy)
 {
   char buf[8];
@@ -124,13 +122,7 @@ _gcry_rndlinux_setup (void)
   do
 {
   _gcry_pre_syscall ();
-  ret =
-# ifdef HAVE_GETRANDOM_SYSCALL
-syscall (__NR_getrandom, buf, 1, GRND_NONBLOCK
-# else
-getentropy (buf, 1
-# endif
-);
+  ret = getentropy (buf, 1);
   _gcry_post_syscall ();
 }
   while (ret == -1 && errno == EINTR);
@@ -139,7 +131,7 @@ _gcry_rndlinux_setup (void)
 }
   else
 rv = (a_rndlinux_have_getentropy != -1);
-#endif /* HAVE_GETENTROPY */
+#endif
 
   if (!rv && !access (NAME_OF_DEV_RANDOM, R_OK)
   && !access (NAME_OF_DEV_URANDOM, R_OK))
@@ -257,7 +249,7 @@ _gcry_rndlinux_gather_random (void (*add)(const void*, size_t,
   /* If we have a modern kernel, try to use the new getentropy function.
* It guarantees that the kernel's RNG has been properly seeded before
* returning any data. */
-#if HAVE_GETENTROPY
+#ifdef HAVE_GETENTROPY
   if (a_rndlinux_have_getentropy != -1)
 {
   long ret;
@@ -388,7 +380,7 @@ _gcry_rndlinux_gather_random (void (*add)(const void*, size_t,
   length -= n;
 }
 
-#if HAVE_GETENTROPY
+#ifdef HAVE_GETENTROPY
 jhave_data:
 #endif
 
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Hello Werner, all.

Steffen Nurpmeso wrote in
<20200529155411.tgyu1%stef...@sdaoden.eu>:
 |Werner Koch wrote in
 |<87sgfjrqf1@wheatstone.g10code.de>:
 ||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 ...
 |out for NAME_OF_DEV_*RANDOM at all .. hmm .. i must admit
 |random/rndlinux.c:_gcry_rndlinux_gather_random() seems strange to
 |me.  :)  Two possible calls to getpid, could be "((apid = XPID) !=
 ...
 |I still would not do it like that, because if software cannot rely
 ...
 |Anyhow, unless i am mistaken from this five minute looking, that
 |random/random-csprng.c:getfnc_gather_random()
 |
 |  #if USE_RNDLINUX
 |if ( !access (NAME_OF_DEV_RANDOM, R_OK)
 | && !access (NAME_OF_DEV_URANDOM, R_OK))
 |  {
 |fnc = _gcry_rndlinux_gather_random;
 |return fnc;
 |}
 |  #endif
 |
 |i would change, maybe with a new call-in to rndlinux.c which
 |should be made responsible for Linux-only environmental detections
 |imho.  Like that it could solely depend on getrandom, and make all
 |the FDs optional, maybe by testing for NOSYS with a one byte read
 |or what at first, or by later aborting if collecting random fails
 |if that is possible.  (For my MUA i use this for seeding only
 |anyhow.)
 |
 ||Are you running in FIPS mode?
 ||
 ||Can you run the Libgcrypt test suite?  In particular
 ||
 ||$ libgcrypt/tests/version
 ||$ libgcrypt/tests/random --verbose --debug

So with the attached patch libgcrypt solely relies upon getentropy
if available, no FD handling is done no more if at all possible.
The test suite passes, a short review makes me think it is alright.

- The setup could block when the OS cannot serve 1 byte of strong
  entropy.  This is different to before, access(2) does not.

  (On the other hand neither on OpenBSD nor on newer Linux (5.4 or
  5.6 i think) this should matter.  And it is likely it does not
  elsewhere, either people seem to have used things like my
  entropy-saver or even hammers like haveged which reveal how
  strange entropy counting was, imho.)

- Some tests aka code places directly reach into
  _gcry_rndlinux_gather_random() and thus only give errors in
  open_device() not the warning that initiated this ML thread.
  This i did not get at first, the tests suite passed nonetheless.

- P.S.: even if this patch is not used, i would suggest an audit
  of this file.

- RANDOM_CONF_ONLY_URANDOM lost its meaning in the past, and this
  patch does not reinstantiate that.  It cannot be done portably,
  except for OSs which provide getrandom(2).

- I shortly thought about using "extern", but i think doing so in
  an isolated fashion is surely wrong.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
commit d37a0f8e (HEAD -> refs/heads/master)
Author: Steffen Nurpmeso 
AuthorDate: 2020-05-29 21:44:59 +0200
Commit: Steffen Nurpmeso 
CommitDate: 2020-05-29 22:03:43 +0200

random/rndlinux.c: avoid redundant actions on FDs if possible
---
 random/rand-internal.h |   5 +-
 random/random-csprng.c |   3 +-
 random/random-drbg.c   |   4 +-
 random/rndlinux.c  | 216 -
 4 files changed, 133 insertions(+), 95 deletions(-)

diff --git a/random/rand-internal.h b/random/rand-internal.h
index d99c6671..4e1298c1 100644
--- a/random/rand-internal.h
+++ b/random/rand-internal.h
@@ -90,10 +90,13 @@ void _gcry_rngsystem_randomize (void *buffer, size_t length,
 
 
 /*-- rndlinux.c --*/
+#if USE_RNDLINUX
+int _gcry_rndlinux_setup (void);
 int _gcry_rndlinux_gather_random (void (*add) (const void *, size_t,
enum random_origins),
-   enum random_origins origin,
+  enum random_origins origin,
   size_t length, int level);
+#endif
 
 /*-- rndunix.c --*/
 int _gcry_rndunix_gather_random (void (*add) (const void *, size_t,
diff --git a/random/random-csprng.c b/random/random-csprng.c
index b06810a0..7ae8 100644
--- a/random/random-csprng.c
+++ b/random/random-csprng.c
@@ -1120,8 +1120,7 @@ getfnc_gather_random (void))(void (*)(const void*, size_t,
  enum random_origins, size_t, int);
 
 #if USE_RNDLINUX
-  if ( !access (NAME_OF_DEV_RANDOM, R_OK)
-   && !access (NAME_OF_DEV_URANDOM, R_OK))
+  if (_gcry_rndlinux_setup () != -1)
 {
   fnc = _gcry_rndlinux_gather_random;
   return fnc;
diff --git a/random/random-drbg.c b/random/random-drbg.c
index 6124f5fb..7f63fade 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -1865,11 +1865,11 @@ _gcry_rngdrbg_reinit (const char *flagstr, gcry_buffer_t *pers, int npers)
 void
 _gcry_rngdrbg_close_fds (void)
 {
-#if USE_RNDLINUX
   drbg_lock ();
+#if USE_RNDLINUX
   _gcry_rndlinux_gather_random (NULL, 0, 0,

Re: libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Hello.

Werner Koch wrote in
<87sgfjrqf1@wheatstone.g10code.de>:
 |On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 |> ./configure \
 |> --prefix=/usr \
 |> --disable-padlock-support \
 |> --enable-static=yes
 |> make
 |> make DESTDIR=$PKG install
 |
 |That is pretty standard except for the --disable-padlock-support - why
 |do you use this?  Padlock is only used on VIA CPUs and has an auditable
 |design in contrast to RDRAND (which is used by Libgcrypt be default).

I am overasked why this is done.  I have not looked for how RDRAND
bugs are handled by libgcrypt either, Werner.  Wait.  Sigh.

Looking at the source it seems libgcrypt knows about the Linux
getrandom systemcall.  Yet it does not seem to know about glibc's
getrandom library function.

Hm, so why does random/random-csprng.c:getfnc_gather_random() look
out for NAME_OF_DEV_*RANDOM at all .. hmm .. i must admit
random/rndlinux.c:_gcry_rndlinux_gather_random() seems strange to
me.  :)  Two possible calls to getpid, could be "((apid = XPID) !=
my_pid || !add)"; ah i see the FDs could become cached (until
fork), .. and then the getrandom syscall is tried even though FDs
have been opened despite its presence.  This, excuse me ;),
i would change quite a bit.  I would not do any FD related thing
at all if getrandom is available, and i, for the MUA i maintain,
simply look for getrandom, library or syscall (the latter came
first; users can explicitly specify via VAL_RANDOM what they want,
though).

Looking at the development version now it finally seems to me that
the library call is supported.

I still would not do it like that, because if software cannot rely
on what has been detected at configuration time all bets are off.
I must admit i do the NOSYS check myself for this thing, but only
for it, not for anything else.  Also not for "system calls" which
change behaviour dependent on library symbol version
(realpath(2/3) comes to mind, exclusively).

Anyhow, unless i am mistaken from this five minute looking, that
random/random-csprng.c:getfnc_gather_random()

  #if USE_RNDLINUX
if ( !access (NAME_OF_DEV_RANDOM, R_OK)
 && !access (NAME_OF_DEV_URANDOM, R_OK))
  {
fnc = _gcry_rndlinux_gather_random;
return fnc;
  }
  #endif

i would change, maybe with a new call-in to rndlinux.c which
should be made responsible for Linux-only environmental detections
imho.  Like that it could solely depend on getrandom, and make all
the FDs optional, maybe by testing for NOSYS with a one byte read
or what at first, or by later aborting if collecting random fails
if that is possible.  (For my MUA i use this for seeding only
anyhow.)

 |Are you running in FIPS mode?
 |
 |Can you run the Libgcrypt test suite?  In particular
 |
 |$ libgcrypt/tests/version
 |$ libgcrypt/tests/random --verbose --debug

Well i could.  Is this still of interest?

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Hello!

Werner Koch via Gnupg-users wrote in
<875zcgtizp@wheatstone.g10code.de>:
 |On Tue, 26 May 2020 15:35, Steffen Nurpmeso said:
 |>   Fatal: no entropy gathering module detected
 |
 |Which version of libgcrypt is that and what build options were used?

Oh, sorry.  That is on CRUX-Linux 3.5

  #?0|kent:$ prt-get info libgcrypt
  Name: libgcrypt
  Path: /usr/ports/opt
  Version:  1.8.5
  Release:  1
  Description:  A general purpose cryptographic library based on GnuPG
  URL:  http://www.gnupg.org
  Maintainer:   Thomas Penteker, tek at serverop dot de
  Dependencies: libgpg-error
  #?0|kent:$ cat /usr/ports/opt/libgcrypt/Pkgfile
  # Description: A general purpose cryptographic library based on GnuPG
  # URL: http://www.gnupg.org
  # Maintainer:  Thomas Penteker, tek at serverop dot de
  # Depends on:  libgpg-error

  name=libgcrypt
  version=1.8.5
  release=1
  source=(ftp://ftp.gnupg.org/gcrypt/libgcrypt/$name-$version.tar.bz2)

  build() {
cd $name-$version

./configure \
--prefix=/usr \
--disable-padlock-support \
--enable-static=yes
make
make DESTDIR=$PKG install

rm -r $PKG/usr/share/info
  }

Our C library is 

  #?0|kent:$ prt-get info glibc
  Name: glibc
  Path: /usr/ports/core
  Version:  2.28
  Release:  2
  Description:  The C library used in the GNU system
  URL:  http://www.gnu.org/software/libc/
  Maintainer:   CRUX System Team, core-ports at crux dot nu
  Files:post-install

and it is configured in essence via

--with-headers=$PKG/usr/include \
--enable-kernel=4.9 \
--enable-add-ons \
--enable-static-nss \
--enable-stack-protector=strong \
--enable-obsolete-rpc \
--enable-obsolete-nsl \
--disable-profile \
--disable-werror \
--without-gd \
--enable-multi-arch

He is a busy Siemens security guy i think, but the ArchLinux
libgcrypt comes on over with the same recipe?

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Hello.

This is maybe the wrong list, but only here i am subscribed and to
me this is one project in the end, but i apologise for that.

Yesterday i installed an OpenBSD 6.7 VM here, and was not able to
start it with my default config (-device virtio-rng-pci) because
libgcrypt failed with

  Fatal: no entropy gathering module detected

(Was quite a journey to find the source of this message...)
Long story short: i finally realized that if i run qemu without
-chroot everything is fine even with virtio-rng, as a workaround
i have created a minimal /dev/ in this chroot so libgcrypt can
access ?random devices.  But i wondered why the fd is not kept
open, you see quite some server related problems if you search the
above.  But further more, is there usage of the system call or the
C library backend on the road?  Shall i even open a bug tracker
thing?

Thanks in advance, Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

(GPG1) Download of false key? Key not included?

[Steffen Nurpmeso]

Hello.

Can anyone tell me what is actually going on here.
If it is as easy as "use GPG2" do not waste that much time,
however, doesn't the below use RSA plus SHA-512, what v1 supports?
( Supported algorithms:
  Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
  Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
  CAMELLIA128, CAMELLIA192, CAMELLIA256
  Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
  Compression: Uncompressed, ZIP, ZLIB, BZIP2

And you will not go for zstd i have seen fly by, right, even
though it decompresses very, very fast, and is a small and self-
sufficient implementation.  Do you.)

  #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg --verify make-4.3.tar.lz.sig
  Reading passphrase from file descriptor 4
  gpg: assuming signed data in `make-4.3.tar.lz'
  gpg: Signature made Sun 19 Jan 2020 11:24:51 PM CET using RSA key ID DB78137A
  gpg: Can't check signature: public key not found

  #?2|kent:gmake.tar_bomb_git-no_reduce$ gpg --search-key DB78137A
  Reading passphrase from file descriptor 4
  gpg: searching for "DB78137A" from hkps server hkps.pool.sks-keyservers.net
  (1) Paul D. Smith 
  Paul D. Smith 
4096 bit RSA key 20C79BB2, created: 2016-10-22
  Keys 1-1 of 1 for "DB78137A".  Enter number(s), N)ext, or Q)uit > 1
  gpg: requesting key 20C79BB2 from hkps server hkps.pool.sks-keyservers.net

  gpg: Total number processed: 1
  gpg:   skipped new keys: 1

Why is it skipped?  GPG1 does support RSA and SHA-512 digests (see
below)?

  $ gpg --list-keys|grep -B1 -A1 Smith
  pub   1024D/6338B6D4 2004-01-04
  uid  Paul Smith (Mad Scientist) 
  sub   2048g/E0EB03CE 2004-01-04

  #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg --delete-keys 6338B6D4
  pub  1024D/6338B6D4 2004-01-04 Paul Smith (Mad Scientist) 

  Delete this key from the keyring? (y/N) y

  #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg -v --search-key DB78137A
  gpg: using character set `utf-8'
  Reading passphrase from file descriptor 4
  gpg: searching for "DB78137A" from hkps server hkps.pool.sks-keyservers.net
  (1) Paul D. Smith 
  Paul D. Smith 
4096 bit RSA key 20C79BB2, created: 2016-10-22
  Keys 1-1 of 1 for "DB78137A".  Enter number(s), N)ext, or Q)uit > 1
  gpg: requesting key 20C79BB2 from hkps server hkps.pool.sks-keyservers.net
  gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
  gpg: armor header: Version: SKS 1.1.6
  gpg: armor header: Comment: Hostname: sks.pod02.fleetstreetops.com
  :public key packet:
  version 4, algo 1, created 1477170443, expires 0
  pkey[0]: [4096 bits]
  pkey[1]: [17 bits]
  keyid: 80CB727A20C79BB2
  :user ID packet: "Paul D. Smith "
  :signature packet: algo 1, keyid 80CB727A20C79BB2
  version 4, created 1477172043, md5len 0, sigclass 0x13
  digest algo 10, begin of digest 3a bd
  hashed subpkt 2 len 4 (sig created 2016-10-22)
  hashed subpkt 27 len 1 (key flags: 03)
  hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
  hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
  hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
  hashed subpkt 30 len 1 (features: 01)
  hashed subpkt 23 len 1 (key server preferences: 80)
  subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2)
  data: [4095 bits]
  :signature packet: algo 17, keyid 96B047156338B6D4
  version 4, created 1477178301, md5len 0, sigclass 0x13
  digest algo 10, begin of digest 93 10
  hashed subpkt 2 len 4 (sig created 2016-10-22)
  subpkt 16 len 8 (issuer key ID 96B047156338B6D4)
  data: [158 bits]
  data: [157 bits]
  :user ID packet: "Paul D. Smith "
  :signature packet: algo 1, keyid 80CB727A20C79BB2
  version 4, created 1477172069, md5len 0, sigclass 0x13
  digest algo 10, begin of digest e3 f0
  hashed subpkt 27 len 1 (key flags: 03)
  hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
  hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
  hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
  hashed subpkt 30 len 1 (features: 01)
  hashed subpkt 23 len 1 (key server preferences: 80)
  hashed subpkt 2 len 4 (sig created 2016-10-22)
  hashed subpkt 25 len 1 (primary user ID)
  subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2)
  data: [4095 bits]
  :signature packet: algo 17, keyid 96B047156338B6D4
  version 4, created 1477178301, md5len 0, sigclass 0x13
  digest algo 10, begin of digest 89 10
  hashed subpkt 2 len 4 (sig created 2016-10-22)
  subpkt 16 len 8 (issuer key ID 96B047156338B6D4)
  data: [160 bits]
  data: [159 bits]
  :public sub key packet:
  version 4, algo 1, created 1477170443, expires 0
  pkey[0]: [4096 bits]
  pkey[1]: [17 bits]
  keyid: 609DAAD35F61D607
  :signature packet: algo 1, keyid 80CB727A20C79BB2

Re: Extraction of public key from an encrypted etc. message

[Steffen Nurpmeso]

ved...@nym.hush.com wrote in <20191118020337.0881ac0...@smtp.hushmail.com>:
 |On 11/15/2019 at 7:26 PM, "Steffen Nurpmeso"  wrote:\
 |The public key _is_ in there, no?
 |=
 |No.
 |
 |Only the public Key ID is in there, not the entire public key, and \
 |and even this keyID can be hidden too,
 |if the sender uses the option of --hidden-encrypt-to

Yes -- thank you very much!  I am reading RFC 2440 again now, it
is a session key created by using the public key only.  I have
this document for so many years now, i had forgotten about it.
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Extraction of public key from an encrypted etc. message

[Steffen Nurpmeso]

Hello.

Is there a way to extract the public key that can be seen when
doing --list-packets from any XY where this very circumstance is
true?

In times where people use Autocrypt headers to distribute their
(stripped etc.) public key with each message they send, it really
makes me a bit sad that when i get a message that actually is
encrypted for the sender and for me i have to download the key
from somewhere else.

The public key _is_ in there, no?
I could not find a solution via web search.

Thanks,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: a new free smime service, but...

[Steffen Nurpmeso]

Robert J. Hansen wrote in <7e1208e4-aa1b-2e4c-3b3b-b74901456101@sixdemon\
bag.org>:
 |> Why doesn't Let's Encrypt offer this service?
 |
 |Because it's outside the scope of what Let's Encrypt exists to do, which
 |is make it easy to provide HTTPS support to small websites.
 |
 |SMTP is *totally* outside of Let's Encrypt's mission.  If you've got a
 |problem with that, take it up with Let's Encrypt.  They're pretty
 |responsive on Twitter at https://twitter.com/letsencrypt.

If i recall correctly Melnikov made a draft how the ACME stuff
could be extended to S/MIME, but it never left draft state.  I do
not listen to the according IETF working groups, ...  Wait, it is
still an active draft, version 6, last updated this year July: [1]
Unfortunately it wants DKIM/SPF/DMARC and a single MIME message
body, which counteracts my desire to vanquish that in favour of
a nice CMS thing that puts list addresses in From:, or so.  Sigh.

  [1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-05

 |> Why isn't CAcert after years of participation listed as trusted CA \
 |> in root
 |> stores?
 |
 |Because CACert hasn't been able to comply with Mozilla's Root Store
 |Policy.  Chrome has its own root store policy, as does Internet
 |Explorer.  CACert hasn't been able to dot the is and cross the ts for
 |any of them, AFAIK.
 |
 |https://www.mozilla.org/en-US/about/governance/policies/security-group/c\
 |erts/policy/

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: a new free smime service, but...

[Steffen Nurpmeso]

Hello,

sorry for the late reply.

Ralph Seichter wrote in <87pninuqns@wedjat.horus-it.com>:
 |* Steffen Nurpmeso:
 |> I think it is common that S/MIME and SSL certificates are delivered
 |> via PKCS12, including the private key. You then seem to extract the
 |> individual things [...]
 |
 |Nope, that is the wrong way round. The correct sequence to obtain an
 |S/MIME certificate is as follows:
 |
 |1. User X creates a private key *locally*. This private key must never
 |be handed to anybody else.
 |
 |2. User X creates a certificate signing request (CSR) and sends it to a
 |certificate authority (CA).
 |
 |3. The CA uses the CSR to create a signed certificate, and sends that
 |certificate back to user X.

Ok, but that is exactly what i have written a few lines later for
the CACert example that i posted, right.  So not nope, Mr.
Where "user X" meant "browser of user X" when i did so for
a StartSSL certificate.  I assume it did the right thing.  But
i do not know.

 |4. User X can then optionally combine private key and signed certificate
 |in a .p12 file to ease importing the data *locally* in his MUA (it is
 |usually more convenient to deal with a single file that combines both
 |private key and certificate).
 |
 |If the process is altered in any way in which a third party gets hold of
 |user X's private key, security is broken, no matter if the private key
 |is password protected or not.

That is surely right.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: a new free smime service, but...

[Steffen Nurpmeso]

P.S.:

Steffen Nurpmeso wrote in <20191023224323.kaodd%stef...@sdaoden.eu>:
  ...
 ||> I think it is common that S/MIME and SSL certificates are
 ||> delivered via PKCS12, including the private key.  You then seem to
 ||> extract the individual things like
 ||
 ||I think this is a severe security breach. The private key should never
 ||leave your computer.

(Yes.)

 ||>   $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
 ||>   $ # Alternatively
 ||>   $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
 ||>   $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes
 ||
 ||>|keys are generated on the subscriber's device and only the public key
 ||>|goes to the CA to be certified.
 |
 |With StartSSL it was like that, the browser generated the signing
 |request i hope.  But i do not know.
 |
 |And, the above i inherited in the manual of the software
 |i maintain.  I have not seen this in the wild on my own.

This is actually only half true.  The original manual only
contains the first of the three.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: a new free smime service, but...

[Steffen Nurpmeso]

Hello,

please excuse the late reply.

Uwe Brauer via Gnupg-users wrote in <874kzz1var@mat.ucm.es>:
 |> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR\
 |> >:
 |>|On Sunday 20 October 2019 at 3:20:41 PM, in
 |>|, Uwe Brauer via Gnupg-users wrote:-
 |>|
 |>|> I just found that
 |>|> https://extrassl.actalis.it/portal/uapub/doProcess
 |>|
 |>|> Provides a free smime certificate.
 |>  ...
 |>|> does somebody know whether there is a security
 |>|> breach, the way this
 |>|> certificate was generated?
 |>|
 |>|I'm no expert but their Certificate Policy reads to me that the
 |>|private key is compromised right from the start. I think usually the
 |
 |> I think it is common that S/MIME and SSL certificates are
 |> delivered via PKCS12, including the private key.  You then seem to
 |> extract the individual things like
 |
 |I think this is a severe security breach. The private key should never
 |leave your computer.
 |
 |>   $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
 |>   $ # Alternatively
 |>   $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
 |>   $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes
 |
 |>|keys are generated on the subscriber's device and only the public key
 |>|goes to the CA to be certified.

With StartSSL it was like that, the browser generated the signing
request i hope.  But i do not know.

And, the above i inherited in the manual of the software
i maintain.  I have not seen this in the wild on my own.

 |> This is possible via CACert.org, at least still (out of money).
 |> You create your local signing request, and the private key.pem never
 |> leaves your own box:
 |
 |>   $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem
 |
 |> (Ensure all email addresses of desire are included in the web
 |> form.)
 |> Unfortunate that besides Comodo there seems no other provider of
 |> free S/MIME certificates.  You can only self-sign, and provide

That i have done myself.

 |Comodo does not offer this any more. At the beginning of the year they
 |reduced the smime cerificates validity from 1 year to 1 month, now they
 |withdraw it all together.

I did not know that.  It was the only free service that i found
when i searched for a free S/MIME certificate last, but i kept
using CACert.org.  (Until i support PGP, when i will switch.)

 |> a safe transport for a certificate to compare with.  Which is why
 |> PGP is so nice.
 |
 |Well yes sort of, but I can tell you from my own experience PGP is more for
 |hackers while smime is not. I have convinced 6 of my friends to use
 |smime, but only one to pgp.
 |
 |Self signed smime certificates are basically useless, because then you
 |have to tell the other user either to install a root certificate or to
 |trust the certificate, in which case smime looses its convenience
 |(compared to pgp)

Well, hm, yes.  What should i say.  It depends a bit, once you
know a certificate is correct some software allow to just agree to
the checksum of a certificate, for example, no need for a root
certificate no more.  To know it is correct you need the
certificate which signed it in what you use as your local pool of
certificate authorities, of course.

I do have GPG keys in may keyring which were not signed by anyone
(when i downloaded them), too, i saw the fingerprint in some
announcement mail or on some website, searched SKS, and downloaded
the one key which did match.  (I think Postfix releases are still
shipped with a gpg1 key sign that is revoked, last i looked,
i always have to look how i can actually use a revoked key
nonetheless.)

Personally i like S/MIME more, because it comes from the same pool
of standards etc. that TLS uses, and the same library can be used
to deal with it, than what i use for TLS anyway.  In theory file
signing and all the other things would be possible via it, too,
the primitives are there, it is just not used in that there are no
omnipresent tools available, like GPG is.

There is no other reason really, except that for mail different
standards for MIME are used, and here i like the PGP one more ;)
That is just how it is, and having said that, i do use PGP since
many years, but only very rarely and mostly automatized (after
having had immense loss due to lost passwords of encrypted
backups).

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: a new free smime service, but...

[Steffen Nurpmeso]

MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR>:
 |On Sunday 20 October 2019 at 3:20:41 PM, in
 |, Uwe Brauer via Gnupg-users wrote:-
 |
 |> I just found that
 |> https://extrassl.actalis.it/portal/uapub/doProcess
 |
 |> Provides a free smime certificate.
 ...
 |> does somebody know whether there is a security
 |> breach, the way this
 |> certificate was generated?
 |
 |I'm no expert but their Certificate Policy reads to me that the
 |private key is compromised right from the start. I think usually the

I think it is common that S/MIME and SSL certificates are
delivered via PKCS12, including the private key.  You then seem to
extract the individual things like

  $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
  $ # Alternatively
  $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
  $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes

 |keys are generated on the subscriber's device and only the public key
 |goes to the CA to be certified.

This is possible via CACert.org, at least still (out of money).
You create your local signing request, and the private key.pem never
leaves your own box:

  $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem

(Ensure all email addresses of desire are included in the web
form.)
Unfortunate that besides Comodo there seems no other provider of
free S/MIME certificates.  You can only self-sign, and provide
a safe transport for a certificate to compare with.  Which is why
PGP is so nice.

 |https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-polic\
 |y.aspx
 |
 |3.2.2 Proving possession of private key
 |
 |The private cryptographic key corresponding to the public key
 |within the certificate is generated by the CA (with a suitable
 |algorithm, size, etc.) and subsequently sent to the subscriberin
 |PKCS#12 for-mat[PFX], via email, thereby insuring that the
 |subscriber does possess the private key.The password needed to
 |import the PKCS#12 file isprovided to the subscriber out-of-band
 |(via web), therefore protecting it from unwanted disclosure to
 |third parties. The CA does not retain such pass-word, so that the
 |legitimate subscriber –assuming that he/she keeps such password
 |confidential –remains the only person able to import the PKCS#12.

Better than nothing.  Sometimes the browser is used to create
thins, i have done that once for StartSSL i think it was (now
defunct).  I would not use this service, however, because why do
they want to do it like that?  They could very well just offer the
one-liner and allow pasting of the signing request, then the
private key would never have been exposed to anyone but the user.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20191021160908.4_hgk%stef...@sdaoden.eu>:
 |Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>:
 ||> Especially if the key is shipped alongside the message already
 ||
 ||Are you sure that it is though? Seems to me you're giving out ill-informed
 ||advice here.
 |
 |Bad advice of mine yes, PGP does not do it the way S/MIME does it.
 ...
 |But you could send a signed message with the public key attached
 |(as application/pgp-keys even?) to the person you want to
 |henceforth communicate encrypted and/or signed.  You need some
 |kind of web of trust to make this fly, however.  But it would
 |make it clear that you have the private counterpart.

Ok, that "clear" is only true if you then just send an encrypted
messae right afterwards.  But that should be it, or am i confused?
I would say that is not an effort too much to gain safe
communication when it is desired.  And then there are other ways
of fetching keys, as long as there are keyservers which one can
use.

Thanks for the sks pool is due at that time.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20191021160908.4_hgk%stef...@sdaoden.eu>:

'Just want to add that the DKIM i refer to in my first message is
in my eyes not a solution but a desastrous demolition ball
of the mail standard, and as such hatred by me, and the reply-to:
that was pointing to Tony Lane's real address is gone if one does
not answer him as a primary and at first glance.

  To: Vincent Breitmoser 
  Cc: Tony Lane via Gnupg-users 

Brain damaged that too.  And i wonder how many archives will be
mutilated and soiled.  What will the next generation think,
definetely not the same that "we" do when we look at messages from
the 80s, for example.  That is the worst business cr.p in a long
time.

(And i apologise shall some g's be missing, my six month old
Lenovo IdeaPad 530S has a keyboard defect; for now i use
a Mode_switch overfay for f, but it's kinda sick.)
 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>:
 |
 |> Especially if the key is shipped alongside the message already
 |
 |Are you sure that it is though? Seems to me you're giving out ill-informed
 |advice here.

Bad advice of mine yes, PGP does not do it the way S/MIME does it.
Sorry, this was not truly intended, i am more used to CMS and
S/MIME, it just came "naturally" out of me.  Side-channel free, so
to say ;}

But you could send a signed message with the public key attached
(as application/pgp-keys even?) to the person you want to
henceforth communicate encrypted and/or signed.  You need some
kind of web of trust to make this fly, however.  But it would
make it clear that you have the private counterpart.

I do stand to my opinion on the Autocrypt header beside that.
I think the OpenPGP: header with a reference to safe transport for
fetching possibilities is more kind and social, and safer, too.

 | - V
 --End of <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Hello Tony.

Tony Lane via Gnupg-users wrote in :
 |On 10/18/19 2:12 PM, Steffen Nurpmeso wrote:
 |> (redacted)... there are drugs and other specialists which
 |> can make you talk and reveal that presence.  At some later time
 |> i would expect a court order to access log etc. data in and of the
 |> brain implant will increase personal rights and freedom.
 |
 |Not exactly. Actually, this is precisely why I find public key 
 |cryptography so cool. If you do not explicitly add your own address
 |to the list of recipients, you will not be able to decrypt the message!

But wait, that is a frantic scenario.

 |This may sound silly, but you may want to write something to someone
 |that you cannot ever possibly be compelled to decrypt. It will be 
 |impossible for you to decrypt, even though you wrote it and encrypted
 |it and even if you have the file in your possession and even if you
 |have all your secret keys and you know all of your own passwords
 |and have them written down. You can smile serenely while they're
 |beating you with a rubber hose, knowing that you can't endanger the
 |lives of your sources, nor give up your rights, even if you felt like
 |that might be entertaining for a change. This is also exactly why
 |governments find it such threat - the idea we have a way to truly,

I find that overly optimistic.  It brought two visual film
impressions, one is the poor guy from within the crate in Pulp
Fiction, that is how you end if you run out of hopes at some time,
it seems.  The other was a French film of a Basque revel (or
freedom fighter if you want to), who was finally caught and
interrogated under drugs.  The drugs made him see (he was a host
before), unfortunately the film ends thereafter with him in
a straitjacket hammering the back of his head against the pad in
some cave cell, trying to get rid of a lot of side channel attacks
(my impression, entirely others may have seen a man gone grazy).

 |securely communicate in a way they cannot prove who sent what
 |terrifies them. It's also what lead to the US trying to classify
 |such crypto as a military munition, which was later repealed in court
 |in Bernstein vs US Department of State. They're trying to bring it
 |back though (hah, fat chance)!

Oh yes, i also have the impression that hysteria gains currency.
A lot of which surely is tactics to gain momentum against chinese
made and designed communication hardware, nevermind the extra
costs of kindling.  (I for one think it is just undemocratic and
antisocial if only one party can spy.  And they all do, more or
less, right.)

And we see ambitions to forbid crypto, or to allow only crypto
with backdoors.  I personally think this will come some day, just
like the implant will, the benefits are too large, just think
about the possibility to get the entire medical history and
current state of a person in an emergency situation.  Criminals
which go to prison by themselves, what do i know :)

 |> Btw., you use autocrypt headers, in this mail of yours there are
 |> thus two certificate keys included.  Unfortunately my MUA not yet
 |> can either of them, and will not before next spring.
 |> At that time we will support PGP/MIME and inline signed/encrypted
 |> messages (even though it will not be nice until some later
 |> time).  And will have a look into OpenPGP: headers.  But not
 |> autocrypt, no.
 |
 |I didn't realize there were people in this mailing list who didn't
 |use it. Well, I turned it off here... that better?

"Thank you" ^_^.  I think yes!  No, i would not, i think it is
a strange thing, of course public keys must come from somewhere,
but passing several hundred or so bytes in each and every mail
message seems like a weird thing to do.  Especially if the key is
shipped alongside the message already, and then headers can be
spoofed, so autocrypt makes sense alongside dkim and such third
party signing environments, which i also dislike, in the form they
come.  (I would prefer a CMS message envelope i think, but sure,
this requires MIME messages.)  I mean, if i want to have signed
communication with someone, i could very well just send her or him
a signed message saying so, and then the key is also where it
belongs, no?  Strange thing...

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Tony Lane via Gnupg-users wrote in :
 |-BEGIN PGP SIGNED MESSAGE-
 |Hash: SHA512

That seems to be a good choice.

 |On 10/17/19 3:38 PM, Steffen Nurpmeso wrote:
 |> You know, i would say people should be advised to use the most
 |> compatible, most secure keys available for their "very key".
 |> Regardless of computing cost that is.  And use specific "weaker",
 |> "faster" or whatever keys for specific purposes, like tarball
 |> signing, or whatever.  I have never understood any other advise,
 |> actually.  I have vague memories of a very "conservative" sentence
 |> on the use of PGP keys on the mentioned FreeBSD handbook page, it
 |> must be more than 15 years, and i have only read it once.
 |> I adhered to that, and i now that all the RSA 4096 things i have
 |> produced ever since will be safe for quite some time, maybe even
 |> until i die (which could happen anytime though), unless the
 |> quantum thing explodes somehow (not a mathematician here).
 |
 |If you absolutely, positively, _need_ the most bits of security then
 |RSA4096 shouldn't be your go-to anymore. RSA4096 doesn't actually
 |provide 4096 bits of security. The _key_ sizes may be 4096 bits, but
 |you must understand the security comes from the the cardinality of
 |prime numbers, so the actual amount of security is only 131 bits of
 |security. Compare this to RSA's 3072 bit keys providing 125 bits of
 |security. Unlike RSA, ECC keys don't scale logarithmically. For ECC,
 |the fields need to be a prime modulus, but that's about it. As a
 |result, the key sizes scale linearly with the bits of security by
 |a factor of 2. So, if you want the most security possible with GPG
 |_today_ you won't beat curve P-521, which provides ~261 bits of
 |security, and to get an equivalent in RSA your key size would need
 |to be at least 15360.
 |
 |But you have to understand, even 128 bits of security is so

I might a bit if i follow this road long enough.

 |incredibly large that even the combined computing power of every
 |processor we have now won't be enough to crack it. See:
 |https://crypto.stackexchange.com/a/48669 for just how effort
 |it'd take.
 |By the way, 256 bits of security isn't twice the amount of 128 bits.
 |129 bits is twice the amount of security of 128 bits. Get it?
 |If you are curious just how much effort it'd take to break a 256 bit
 |key, I'd argue that it's physically impossible because there simply
 |isn't enough energy in the universe to break it... see:
 |https://youtu.be/S9JGmA5_unY

My download is excessed until the 22nd.  But will throw an eye.

 |But I digress. It's not the bits of security that matter anymore.

For me the fascinating thing in this area are all those ideas
which human minds had to not have a need to do brute force
searching.  Regarding my GPG passwords i think nothing much can be
done about that though, except restricting the search to the bytes
that pass "tr -cd 'a-zA-Z0-9_.,=@%^+-'", but which is already
a significant reduction.

 |You have a far bigger chance of being insecure with side-channel
 |attacks etc, than you are with not enough bits of security. That is
 |a far bigger security hole... Being on a device that is exposed

Yeah, the passwords which were stolen by talking in my sleep are
a real problem.

 |to the internet. That's where you'd get cracked. Not the key size
 |being too small.

Actually i do not think that is really true, or only by accident.
I think the problems are theft, trojan horses, threat of force,
and that unfortunately includes coercive detention also (maybe
also only and even) in our western first world.  So even with what
for example FreeBSD has, where you can have some space on your
harddisk which looks like random data but actually contains an
encrypted partition, (i am pretty sure in the Linux world this is
also doable somehow), there are drugs and other specialists which
can make you talk and reveal that presence.  At some later time
i would expect a court order to access log etc. data in and of the
brain implant will increase personal rights and freedom.

And not the key size being too small may likely be true, but
shortly after Y2K i am pretty sure to remember right that the
"usual defaults" where 1024 bits for RSA or so, and whoever
followed that advise and had some records protected by such a key,
and there are records which are of real value, might have or look
forward to problems if they got lost.  Which thus brings me back
to the FreeBSD developer handbook entry which talked about 4096
bit keys around that time.

So yes, an excursion like yours is pretty cool and of value, and
experts do know, but for "normal people" i would always favour the
best thinkable default.  For that audience that EC stuff may also
just work, then.  I mean, the thing is that "normal people"
usually never get to use GnuPG directly anyway, and having the
best defaults i

Re: FAQ: seeking consensus

[Steffen Nurpmeso]

Robert J. Hansen wrote in <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemon\
bag.org>:
  ...
 |1.  How should we handle the SKS keyserver attacks?
  ...
 |Another says, "with a recent GnuPG release SKS may be used productively
 |and we should keep the current advice."

I am using them, and have had the sks-keyservers.net in my own
cacert pool for a long time.  I do only import rarely, very
specific keys, and only with supervision, however.  It has always
been like that, and i also always clean keys, since i personally
never really had a glue onto the PGP approach of that web of trust.
I still whimper that the new German passports did not ship with
SSL and PGP keys/certificates.  But that is something different.

  ...
 |2.  What should be done about the FAQ's guidance to use RSA-2048?
 |
 |First, I think everyone agrees it should be removed, as it's just not
 |accurate any more; we've defaulted to RSA-3072 for some time.
 |
 |One option is, "remove it and update the text to refer to RSA-3072, our
 |current default."
 |
 |Another is, "remove it and update the text to refer to ECC, which will
 |be our next default."  (If so: which curve and which lengths do you
 |think should be the default?)
 |
 |(Again, third, fourth, and fifth ways are welcomed.)

This mail only because i want to point out that, if i remember
this correctly, the majority of FreeBSD committers who had a PGP
key used RSA 4096 already in 2002, or around that time.  (4.7
times i think these were.)

 |3.  What should we advise people about their existing RSA-2048 keys?
 |
 |"There's no rush, but migrating them to [whatever our new guidance is]
 |at a deliberate pace is advised, since RSA-2048 isn't expected to be
 |generally safe past 2030"
 |
 |or
 |
 |"Your existing RSA-2048 keys are fine, you don't need to take any action"
 |
 |(Again, third, fourth, and fifth ways are welcomed.)

You know, i would say people should be advised to use the most
compatible, most secure keys available for their "very key".
Regardless of computing cost that is.  And use specific "weaker",
"faster" or whatever keys for specific purposes, like tarball
signing, or whatever.  I have never understood any other advise,
actually.  I have vague memories of a very "conservative" sentence
on the use of PGP keys on the mentioned FreeBSD handbook page, it
must be more than 15 years, and i have only read it once.
I adhered to that, and i now that all the RSA 4096 things i have
produced ever since will be safe for quite some time, maybe even
until i die (which could happen anytime though), unless the
quantum thing explodes somehow (not a mathematician here).

I still have to log into SSH hosts which do not support anything
but RSA (i have only ever used RSA keys, not DSA i think it was,
and am using ED25519 for an increasing number of other hosts).

(P.S.: personally i am also still using GnuPG v1.4.23, in my
private path, even though i have 2.2.17 in /usr here, and the
rotating head of ArchLinux also ships the new one, etc. etc.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Steffen Nurpmeso]

Teemu Likonen wrote in <87zhlvta73@iki.fi>:
 |Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote:
 |
 |> My question: is there any better way than a shell script over
 |> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in
 |> my keyring (with gpg1)?
 |
 |It seems that there is no better way than scripting it. My "--edit-key +
 |clean" script is below. It can be changed to "minimize".
 |
 |#!/bin/sh
 |gpg --batch --with-colons --list-keys | awk -F: '
 |$1 == "pub" {pub = 1}
 |pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \
 | xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key
 --End of <87zhlvta73@iki.fi>

Ah, thanks.  Cool!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Steffen Nurpmeso]

Werner Koch via Gnupg-users wrote in <87lfxfsiz0@wheatstone.g10code.de>:
 |On Tue,  2 Jul 2019 11:00, d...@fifthhorseman.net said:
  ...
 |import-clean does this:
 ...
 |[.]In contrast import-minimal
 |does this
 ...

I (still user of GPG1, it is only your newer key which this cannot
do for me) had

  export-options no-export-attributes,export-clean
  #import-options import-clean,merge-only
  import-options import-minimal,merge-only
  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options check-cert 
ca-cert-file=/home/steffen/sec.arena/pgp.git/sks-keyservers.net

in gpg.conf (also because the in-town TU Darmstadt key server is
of a terrible sort), but changed to import-minimal now, as above.
I note that after --refresh-keys all the signatures are still in
the DB, and even a truly updated key just loaded more signatures.
My question: is there any better way than a shell script over
--list-keys --with-colon | grep ^pub | ...etc... to "minimize"
keys in my keyring (with gpg1)?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: GnuPG and SSH_AUTH_SOCK value

[Steffen Nurpmeso]

Daniel Kahn Gillmor via Gnupg-users wrote in <87ftnup18e.fsf@fifthhorsem\
an.net>:
 |On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote:
 |> On 23.06.19 12:21, Matthias Apitz wrote:
 |>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
 |>
 |> This makes your setup depend on a suid binary.
 |
 |Can you give more details?  I know that some older systems did rely on X
 |or startx or something being setuid, but i think more modern systems
 |don't require that.  On a debian testing (buster) system, for example, i
 |don't believe that any of the binaries are suid.

..because some packagers do CRUX to avoid it, maybe because they
do not want to violate some policy.
For example, for the MUA i maintain, Debian ships with the
privilege-separated "dotlock" helper, but does not install it
SETUID.  This is good enough for the shared mail directory the way
Debian does it, in fact the package maintainer is pretty clever,
right, but of course this is not how it is designed; today: it was
a SETGID helper in the past, but that does not work on eg. OpenBSD
where only root can write in the mail spool.  And since this MUA
supports multiple mail spools, it will not work unless they are
setup in exactly the same way.  But only normal file-locking, as
is the chosen approach on OpenBSD (for my MUA), is not the way the
Debian maintainer wants to go.  Well, this is his choice.

(Besides i am in total favour of not having SETUID, not only
because i had a CVE myself.  Here Xorg still is SETUID, but i have
never looked too deep.  For graphics hardware access, you need to
have access to hardware, no.  Ie., whether hardware is designed so
that this becomes possible, i do not know.  Being able to start
a program SETUID, open some files, and then enter a restricted
mode which has lost root rights, i do not feel bad about.  Like
the FreeBSD capsicum thing, or even CloudABI.  Maybe i even prefer
being able to search SETUID and have a list, instead of having
very complicated configuration settings, and CRUX, hidden here and
there.  But i am not a security researcher, i just try to do
a little thing right.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt

[Steffen Nurpmeso]

A nice Monday afternoon i wish, i have a post scriptum.

Steffen Nurpmeso wrote in <20180604134413.sljyg%stef...@sdaoden.eu>:
 |Last saturday i search/stumbled over an interesting Debian page
 |(Subkey.html) which describes how to generate a dedicated siging
 |subkeys, and how to create a new key pool via
 |--export-secret-subkeys which does not contain (all parts of) the
 |real private key, so that the secret key can be stored "somewhere
 |else" but the newly reimported secret (sub)key can still be used
 |for signing purposes.
 ...
 |(sorry), i cannot find a bug in the bug-db that corresponds to the
 |behaviour i see, and that is that i neither can --export the
 |public key from that mutilated private key and use that one for
 |--encrypt'ion, nor can use the key itself for that (the encryption
 |key seems "hidden", but if i "toggle" --edit-key then i can see it
 |still).  But i can use it for signing purposes.

So i ended up with two directories, pgp-backup.git without
secring.gpg and only the public key which can encrypt, and
pgp.git, which is ~/.gnupg, has the mutilated private key, and can
sign.

Just ten minutes ago however i have found out that if i --export
the key from pgp-backup.git and --import it into pgp.git, then the
latter gains encryption capabilities again!  I thought i had tried
that with the GNUPGHOME which has the full private key, and
failed, but maybe i was in a state of confusion by then (already).
Anyway, this new --import mysteriously said

  Reading passphrase from file descriptor 4
  gpg: key ... 2 new signatures
  gpg: key .. 1 new subkey
  gpg: Total number processed: 1
  gpg:new subkeys: 1
  gpg: new signatures: 2

and i now have the signature for the newly created signing subkey
two times, and encryption works.
~/.gnupg is now fully functional again!

Ciao from within the Greyness,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt

[Steffen Nurpmeso]

Hello.

Last saturday i search/stumbled over an interesting Debian page
(Subkey.html) which describes how to generate a dedicated siging
subkeys, and how to create a new key pool via
--export-secret-subkeys which does not contain (all parts of) the
real private key, so that the secret key can be stored "somewhere
else" but the newly reimported secret (sub)key can still be used
for signing purposes.
  
I did not know about that yet, unfortunately, and have started to
use the "normal" key, so that possible users will have to reimport
the updated key.  But because it is a really great thing to be
able to move the complete private key somewhere else, and to have
the remains with a different password at hand, i did that.

So despite the fact that noone is interested in that long story
(sorry), i cannot find a bug in the bug-db that corresponds to the
behaviour i see, and that is that i neither can --export the
public key from that mutilated private key and use that one for
--encrypt'ion, nor can use the key itself for that (the encryption
key seems "hidden", but if i "toggle" --edit-key then i can see it
still).  But i can use it for signing purposes.

My question: is this a bug that --export does not yield a valid
public key that can be used for --encrypt'ion, and that the key as
such cannot be used for that, too?  Shall i open a bug report.

Thanks!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: A postmortem on Efail

[Steffen Nurpmeso]

Ben McGinnes  wrote:
 |On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote:
 |> On 21/05/2018 13:34, Ben McGinnes wrote:
 |> 
 |>> I agree with most of the article and largely with the need to break
 ...
 |Mine too, it's why I keep a copy of 1.4 installed at all.  It's been a

I only use v1.4, and i will never never never never use anything
newer because that is very large and consists of an immense amount
of components that i really do not need.  I receive keys via
hkps:// and sign, verify, encrypt and decrypt.  Having no pinentry
is a bit of a problem, also because ~/ expansion is not possible
in gpg.conf; but i have a small mkfifo program that feeds in the
passphrase as appropriate, so this works for me.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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