Re: packet syntax

[edgar]

On Apr 12, 2018 3:39 AM, Werner Koch  wrote:
>
> On Thu, 12 Apr 2018 05:29, ed...@pettijohn-web.com said:
>
> > did a hexdump of the file and the first word is `99' which in binary
> > would be `10011001'. I was expecting to encounter `11000110'.  I'm
>
> OpenPGP (RFC-4880) has several ways to encode a packet header.  This
> first byte is called the CTB and reads:
>
>   0x10011001 
>  !##-  0x01  = 2 length bytes follow.
>  !!--- 0x06  = Public key
>  ! Clear = Old style CTB
>   0x11000110  
>  !^^
>  !!--- 0x06 = Public Key
>  ! Set  = New style CTB
>
> For a new style CTB the length bytes are Hufmann like encoded.  Bit 7 is
> always set.  A basic parser can be found in gpgme/src/data-identify.c
>

Cool. I'll check that out.

Thanks
>
> Shalom-Salam,
>
>    Werner
>
> -- 
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: packet syntax

[edgar]

On Apr 12, 2018 2:30 AM, FuzzyDrawrings via Gnupg-users <gnupg-users@gnupg.org> 
wrote:
>
> Edgar Pettijohn wrote:
>
> > the first word is `99' which in binary would be 
> > `10011001'. I was expecting to encounter `11000110'.
>
> You were expecting the packet header to be written in the "new" format, but 
> it is actually written in the "old" format (indicated by it beginning with 
> "10" vs "11"). See RFC-4880 section 4.2.

This is what I thought I was seeing, but thought I read somewhere that gpg 
creates version 4 packets.  Thanks.
>
> Public key packets have a Tag ID of 6, and the "new" format isn't required 
> unless the packet has a Tag ID greater than 15. 
>
> -fuzzy
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

packet syntax

[Edgar Pettijohn]

I'm trying to learn the pgp packet syntax. I created a new key with gpg2 
--gen-key and then gpg2 --export > pubkey.key and then gpg2 --dearmor 
pubkey.key. Which left me with a pubkey.key.gpg file. I then did a 
hexdump of the file and the first word is `99' which in binary would be 
`10011001'. I was expecting to encounter `11000110'.  I'm thinking that 
perhaps I have missed something simple and just need a nudge in the 
right direction.


Thanks in advance,


Edgar


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

Re: GnuPG installation

[Edgar Pettijohn]

On 03/21/18 15:27, BRIONES Bobby wrote:

Hi,
Thanks for responding.
We are using linux.

Bobby


Which flavor? You will need to find out whatever the package manager is 
for whichever flavor of linux you are using. You will need root 
permissions either through su(1) or sudo(8).


Or you can download and compile yourself. It may be as easy as:

# ./configure && make && make install



-Original Message-
From: ed...@pettijohn-web.com [mailto:ed...@pettijohn-web.com]
Sent: Wednesday, 21 March 2018 10:25 PM
To: BRIONES Bobby; gnupg-users@gnupg.org
Subject: Re: GnuPG installation


On Mar 20, 2018 4:10 PM, BRIONES Bobby  wrote:

Hi,

  


I have the following questions about the abovementioned package,  can someone 
help me please:

  


What access do I need to be able to install the software?


You may want to mention what OS you are using.



Do I just download the software and install? What about access to our existing 
folders used in our SFTG/transfer of files?

  

  


Regards,

  


Bobby Briones
Technical Test Analyst

IT | Corporate

T (0288492011)

M (0431459917)

www.rms.nsw.gov.au
Every journey matters

  


Roads and Maritime Services
Level 4 27-29 Argyle St Parramatta NSW 2150

  


Before printing, please consider the environment

IMPORTANT NOTICE: This email and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. Roads and Maritime Services is not 
responsible for any unauthorised alterations to this email or attachment to it. 
Views expressed in this message are those of the individual sender, and are not 
necessarily the views of Roads and Maritime Services. If you receive this email 
in error, please immediately delete it from your system and notify the sender. 
You must not disclose, copy or use any part of this email if you are not the 
intended recipient.

Before printing, please consider the environment

IMPORTANT NOTICE: This email and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. Roads and Maritime Services is not 
responsible for any unauthorised alterations to this email or attachment to it. 
Views expressed in this message are those of the individual sender, and are not 
necessarily the views of Roads and Maritime Services. If you receive this email 
in error, please immediately delete it from your system and notify the sender. 
You must not disclose, copy or use any part of this email if you are not the 
intended recipient.



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

Re: GnuPG installation

[edgar]

On Mar 20, 2018 4:10 PM, BRIONES Bobby  wrote:
>
> Hi,
>
>  
>
> I have the following questions about the abovementioned package,  can someone 
> help me please:
>
>  
>
> What access do I need to be able to install the software?
>

You may want to mention what OS you are using.


> Do I just download the software and install? What about access to our 
> existing folders used in our SFTG/transfer of files?
>
>  
>
>  
>
> Regards,
>
>  
>
> Bobby Briones
> Technical Test Analyst
>
> IT | Corporate
>
> T (0288492011)
>
> M (0431459917)
>
> www.rms.nsw.gov.au
> Every journey matters
>
>  
>
> Roads and Maritime Services
> Level 4 27-29 Argyle St Parramatta NSW 2150
>
>  
>
> Before printing, please consider the environment
>
> IMPORTANT NOTICE: This email and any attachment to it are intended only to be 
> read or used by the named addressee. It is confidential and may contain 
> legally privileged information. No confidentiality or privilege is waived or 
> lost by any mistaken transmission to you. Roads and Maritime Services is not 
> responsible for any unauthorised alterations to this email or attachment to 
> it. Views expressed in this message are those of the individual sender, and 
> are not necessarily the views of Roads and Maritime Services. If you receive 
> this email in error, please immediately delete it from your system and notify 
> the sender. You must not disclose, copy or use any part of this email if you 
> are not the intended recipient.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: entropy gathering daemon

[edgar]

On Feb 28, 2018 8:22 AM, Werner Koch <w...@gnupg.org> wrote:
>
> On Sun,  4 Feb 2018 08:44, ed...@pettijohn-web.com said:
>
> > Is it no longer possible to use egd? Most of the info I can find seems
>
> If Libgcrypt has been configured with EGD support this should still
> work.  I have not tested it for more than a decade, though.
>
> Why do you want to use it?  Which OS does not support /dev/random and
> why don't you want to use the fallback rndunix driver in Libgcrypt.
>
>
> Shalom-Salam,
>
>    Werner
>

I overlooked the configure switches. Got it working. The use case is for 
chroot'd programs that need it on a filesystem mounted nodev. I sent some 
patches awhile back to add arc4random_buf as the entropy gathering 'device'. 
Which I've been using with no problems since. And it's a little faster than 
going through the egd.

Thanks,

Edgar
>
> -- 
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[edgar]

On Feb 19, 2018 12:45 PM, Daniel Kahn Gillmor  wrote:
>
> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.  Some of
> these dependencies are "brittle".
>
> Brittle software dependencies
> -
>
> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).  What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.  GnuPG's UI has been constantly
> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.
>
> For historical reasons, there are a number of tools that were built
> around some element of the GnuPG UI that was current at the time the
> tool was built.  Even worse, there are a number of tools that assume
> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements
> within its internal storage).  Newer versions of GnuPG do different
> things with its internal storage (and as users we get benefits from
> those improvements).
>
> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.
>
> A case study
> 
>
> For example, the current stable version of the Debian operating system
> is Debian 9 ("stretch"), and it ships a version of the "modern" branch
> of GnuPG.
>
> As one of the GnuPG maintainers for Debian, i was hoping at one point to
> backport the "modern" version of GnuPG to the previous version of Debian
> (Debian 8, "jessie"), which some people still run on servers.  I found
> that such an upgrade would break at least a half-dozen other packages in
> Debian jessie *that i knew of* [0] -- and their breakage would in turn
> likely affect some number of other packages.  This was not an exhaustive
> survey of all possible bugs, just the most visible ones. :/
>
> I have personally given up on the project of backporting modern GnuPG to
> "jessie", because i think what time i can devote to GnuPG maintenance is
> better-spent elsewhere.  I don't have the bandwidth to cope with the
> resultant bug reports in other packages that such a backport would
> produce.  Generally, i encourage users of "jessie" to uprade their
> entire OS to the current version of debian stable, and to take advantage
> of the improvements to GnuPG that way.
>
> What can we do?
> ---
>
> The problems described above point to problems in the ecosystem *around*
> GnuPG, but it also points to concerns about GnuPG's presentation of its
> capabilities *to* the rest of the ecosystem.  To the extent that GnuPG
> offers features that other tools might want to use, when those features
> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.
>
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.  It also doesn't have bindings in many
> popular programming languages.  When programmers in those language want
> to use GnuPG, their shortest path to "something that works" often
> involves shelling out to gpg, rather than binding to GPGME. :/ 

That doesn't sound secure. Probably shouldn't use such programs on a server. 
Gpgme looks to do everything that it needs to do. Can you specify a function it 
is missing? 

>
> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.  Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce
> warnings?
>
> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in 

Re: How can we utilize latest GPG from RPM repository?

[Edgar Pettijohn]

On 02/17/18 17:06, helices wrote:
I will probably never understand why wanting to run the most current 
version of gnupg on a plethora of servers is controversial.


Nevertheless, the two (2) greatest reasons are:

 1. PCI DSS v3.2
 2. PCI DSS compliance audits

Being able to demonstrate that we are using the latest, greatest 
encryption available on every one of our hosts, simplifies that 
portion of the audit equation more than you probably believe.


Furthermore, following feature not availabe in 2.0.22 are more than 
nice-to-haves:


  * The file secring.gpg is not used to store the secret keys anymore.
  * All support for PGP-2 keys has been removed for security reasons.
  * The standard key generation interface is now much leaner.
  * Commands to create and sign keys from the command line without any
extra prompts are now available.
  * There is no more need to manually start the gpg-agent.
  * A new format for locally storing the public keys is now used.
  * Revocation certificates are now created by default.
  * The format of the key listing has been changed to better identify
the properties of a key.


Apparently, there is no current solution to our problem similar to 
that we found for our rsyslog example. That is too bad. We will get 
over our disappointment.


However, let it be said here and now, if the gnupg community wants the 
use of gnupg to spread far further than a clique of geeks, making its 
use easier for non-geeks is probably the simplest and most direct way.


Yes, that is my opinion, humble or otherwise.

YMMV

Are there any other questions before I get a direct answer to my 
original subject question?


Thank you.


On Wed, Feb 14, 2018 at 2:20 PM, helices > wrote:


CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.

We want to move to v2.2.x, and stay current, but we don't want to
download source and compile for dozens of systems.

We want all users to be using the same version all of the time.

Please, advise. Thank you.



Pay someone to package it for you.



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


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

RE: How can we utilize latest GPG from RPM repository?

[edgar]

On Feb 15, 2018 9:06 AM, "Lightner, Jeffrey"  wrote:
>
> What you’re missing is WHY you want a later upstream version.   Is there a 
> specific feature you’re needing that isn’t in the one that comes with your 
> distro?
>
>  
>
> You can’t have it both ways:  You want to stay on a stable distro/version 
> which is the raison d’etre for RHEL/CentOS but want to have the latest 
> package.    As I noted in my prior post you can get the latest of everything 
> by abandoning CentOS in favor of Fedora at the expense of stability.    Your 
> choice of distro is based on many factors.   Some people even build their own 
> packages all from scratch because they don’t like any of the distros.  
>

Just to add a little extra. Say you have 12 machines. Use one as your build box 
and just build and install to a fake root tar it up and untar it on the rest of 
the machines. Make a few simple scripts to keep track of what files are 
associated with each "package" so you can easily delete them later. Most 
distros packaging systems are too difficult in my humble opinion. Plus you will 
get the software you want built to your needs.

>  
>
> Not all packages have people that build rpm’s for them.   Many FOSS projects 
> seem to prefer building for Debian or something else and MAY package it for 
> whatever distro they like but some don’t package it for anything and expect 
> you to do the legwork yourself.
>
>  
>
> In general if it isn’t in RHEL/CentOS I look for it in the EPEL.  If it isn’t 
> there I almost always download the source then configure/compile it.   This 
> isn’t really a difficult process for most packages.  
>
>  
>
> There ARE other locations that MAY provide a package you want.   Have you 
> looked at rpmfind?  rpmbone?
>
>  
>
> And of course YOU could create the rpm and share it on EPEL yourself so 
> others will have it.
>
>  
>
>  
>
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of helices
> Sent: Thursday, February 15, 2018 9:10 AM
> To: gnupg-users@gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
>  
>
> Yes, I know that.
>
> In general, that scheme works well.
>
> However, in another case, rsyslog, a certain function has been broken for 
> many years, and the only fix is to track the developers' most recent 
> versions. In that case, the developers maintain their own repository: 
> http://rpms.adiscon.com ; which is easy to incorporate into: 
> /etc/yum.repos.d/rsyslog.repo
>
> We are hoping something similar is available for gnupg. I have not found 
> that; which is the reason for my posts here.
>
> What am I missing?
>
> Please, advise. Thank you.
>
>  
>
>  
>
> On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey  
> wrote:
>
> CentOS isn't a vendor.   It is a project that does binary compiles of RHEL 
> sources.
>
> RedHat is the vendor that creates RHEL and its source is used to make CentOS. 
>   RHEL is supported by RedHat if you have a subscription.  CentOS has no 
> direct support though RedHat hosts the project nowadays.
>
> RHEL (and therefore CentOS) major versions such as 7 start with base upstream 
> versions of packages.   RedHat modifies that base upstream package to 
> backport bug and security fixes from later upstream packages if relevant to 
> the original base.   They then add extended versioning to the RPM name.
>
> For example on a test system I just looked at  "yum list gnupg2" shows:
> Installed Packages
> gnupg2.x86_64                  2.0.22-3.el7                   @anaconda/7.0
> Available Packages
> gnupg2.x86_64                  2.0.22-4.el7                   
> rhel-7-server-rpms
>
> Notice the base upstream for both the installed and the available is 2.0.22 
> but the extended versioning is different (3.el7 vs 4.el7).   You'd have to 
> examine the errata to see what is different about the latter.
>
> In general unless there is a specific feature in upstream you need that is 
> not in the RHEL/CentOS provided version you should use the RHEL/CentOS 
> version on your RHEL/CentOS system.
>
> If you really want the latest of everything you should use Fedora instead of 
> CentOS.   Just be aware that Fedora is bleeding edge and releases a new 
> version twice a year.   Generally that means you HAVE to do a full upgrade at 
> least once a year as they won't offer updated packages for more than two 
> major versions at a time.   For a Production environment that pace of upgrade 
> is usually not desirable which is why people use RHEL/CentOS instead.
>
>
> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Daniel 
> Kahn Gillmor
> Sent: Wednesday, February 14, 2018 5:31 PM
> To: helices; gnupg-users@gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
> On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> > CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> >
> > We want to move to 

Re: [patches] add support for arc4random_buf()

[edgar]

On Feb 6, 2018 6:35 AM, Werner Koch <w...@gnupg.org> wrote:
>
> On Tue,  6 Feb 2018 06:25, ed...@pettijohn-web.com said:
> > Please see attached patches to add support for arc4random_buf() as an
> > alternate to /dev/{u}random. I tried to be as unobtrusive as possible
> > and maintain style. It should also allow the user to still define
> > RANDOM_CONF_ONLY_URANDOM if they would prefer to use
> > /dev/urandom. This will allow gpg to be used on filesystems mounted
> > nodev while providing quick, quality randomness.
>
> Please describe what arc4random_buf is and where it is used.

The manual is probably the best source of information.

http://man.openbsd.org/arc4random

However, the tldr.

arc4random_buf() fills the buffer with nbytes of random data using the ChaCha20 
cipher. It is thread safe. Every call stirs it more adding to it's randomness.

Thanks,

Edgar
>
> I also redirect this to the libgcrypt mailing list.
>
>
> Salam-Shalom,
>
>    Werner
>
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[patches] add support for arc4random_buf()

[Edgar Pettijohn]

Please see attached patches to add support for arc4random_buf() as an 
alternate to /dev/{u}random. I tried to be as unobtrusive as possible 
and maintain style. It should also allow the user to still define 
RANDOM_CONF_ONLY_URANDOM if they would prefer to use /dev/urandom. This 
will allow gpg to be used on filesystems mounted nodev while providing 
quick, quality randomness.



Thanks,


Edgar Pettijohn

--- configure.ac	Wed Dec 13 07:51:33 2017
+++ /home/edgar/libgcrypt-1.8.2/configure.ac	Mon Feb  5 19:59:17 2018
@@ -1721,7 +1721,7 @@
 # Other checks
 AC_CHECK_FUNCS(strerror rand mmap getpagesize sysconf waitpid wait4)
 AC_CHECK_FUNCS(gettimeofday getrusage gethrtime clock_gettime syslog)
-AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile)
+AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile arc4random_buf)
 
 GNUPG_CHECK_MLOCK
 
--- rndlinux.c	Thu Nov 23 12:16:58 2017
+++ /home/edgar/libgcrypt-1.8.2/random/rndlinux.c	Mon Feb  5 23:18:20 2018
@@ -154,6 +154,30 @@
 }
 
 
+/* This is the least obtrusive way I could find */
+#if defined(HAVE_ARC4RANDOM_BUF)
+  if (!only_urandom)
+{
+  do
+{
+  size_t nbytes;
+
+  nbytes = length < sizeof(buffer) ? length : sizeof(buffer);
+  /* always successful */
+  arc4random_buf (buffer, nbytes);
+
+  (*add)(buffer, nbytes, origin);
+  want = want - nbytes;
+   } while (want);
+
+  wipememory (buffer, sizeof buffer);
+
+  return 0; /* success */
+}
+
+#endif /* HAVE_ARC4RANDOM_BUF */
+
+
   /* First read from a hardware source.  However let it account only
  for up to 50% (or 25% for RDRAND) of the requested bytes.  */
   n_hw = _gcry_rndhw_poll_slow (add, origin);
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

entropy gathering daemon

[Edgar Pettijohn]

Is it no longer possible to use egd? Most of the info I can find seems 
rather old, and so far I haven't been able to find a way to make it 
work. If it is still possible how do I do it.


Thanks in advance,


Edgar


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

Where is /usr/local/gnupg-2.1?

[Edgar Suter]

I am trying to configure Enigmail for Thunderbird on my Intel Core 2 Duo iMac 
running OSX 10.10.5. 

When attempting the autoinstallation, the Wizard hung up at the “downloading” 
popup. Time passed without any downloading as indicated on the screen shot from 
the Wikipage.



So, I went to the GnuPG site and I was able to download GnuPG-2.1.11. I 
received a “Installation successful” message, but the Thunderbird/Enigmail 
Set-up Wizard cannot find the files automatically. Too, I am unable to manually 
“Browse" to find the files. The website suggests: "The software will be 
installed to /usr/local/gnupg-2.1.”  However I search and look manually and am 
unable to find such a file location.

If you can help I would be most appreciative.

Ed


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