How do I prevent gpg from including SHA1?

Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
apt-get is complaining that signatures are invalid and that the InRelease file is not signed (see Using Centos to sign .deb packages for background). On the server, I have verified using gpg that InRelease is in fact signed.
Per Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:", one needs to do the following:
Adjust the personal-digest-preferences and personal-digest-preferences
in $HOME/.gnupg/gpg.conf to eliminate SHA-1 from one's GPG
preferences. This prevents the problem coming back with new keys.
Upon reviewing my reprepro setup, I have SHA1 shown under both the Release file (and the InRelease clearsign signature) and the individual Packages file, so I hope doing this will be successful.
~/.gnupg/gpg.conf seems to indicate that I will use hash algorithms as described by the default-preference-list, and then lists which ones to use first if available.
[michael@bigbox ~]$ cat ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512
man gpg states:
--personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg --version to get a list of available
algorithms, and use none to set no preference at all. This allows the
user to safely override the algorithm chosen by the recipient key
preferences, as GPG will only select an algorithm that is usable by
all recipients. The most highly ranked digest algorithm in this list
is also used when signing without encryption (e.g. --clear-sign or
--sign).
And I see gpg --version in fact shows SHA1 as being included.
michael@bigbox ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, 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
I only have one key.
[michael@bigbox ~]$ gpg --list-keys
/home/michael/.gnupg/pubring.gpg
--------------------------------
pub 2048R/542342AE 2018-02-08
uid Michael Jones <tenthousandants@gmail.com>
sub 2048R/4D73CC3A 2018-02-08
And give it a try...
[michael@bigbox ~]$ gpg --edit-key 542342AE
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 2048R/542342AE created: 2018-02-08 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/4D73CC3A created: 2018-02-08 expires: never usage: E
[ultimate] (1). Michael Jones <tenthousandants@gmail.com>
gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)
Is SHA1 still there?
Note that the above referenced post Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:" states that one must adjust the personal-digest-preferences in $HOME/.gnupg/gpg.conf twice, so I am concerned that potentially there is something else which needs to be changes.
I don't think it matters, but I am running Centos7.
How do I prevent gpg from including SHA1?
gpg gnu hashsum signature
add a comment |Â
up vote
3
down vote
favorite
apt-get is complaining that signatures are invalid and that the InRelease file is not signed (see Using Centos to sign .deb packages for background). On the server, I have verified using gpg that InRelease is in fact signed.
Per Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:", one needs to do the following:
Adjust the personal-digest-preferences and personal-digest-preferences
in $HOME/.gnupg/gpg.conf to eliminate SHA-1 from one's GPG
preferences. This prevents the problem coming back with new keys.
Upon reviewing my reprepro setup, I have SHA1 shown under both the Release file (and the InRelease clearsign signature) and the individual Packages file, so I hope doing this will be successful.
~/.gnupg/gpg.conf seems to indicate that I will use hash algorithms as described by the default-preference-list, and then lists which ones to use first if available.
[michael@bigbox ~]$ cat ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512
man gpg states:
--personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg --version to get a list of available
algorithms, and use none to set no preference at all. This allows the
user to safely override the algorithm chosen by the recipient key
preferences, as GPG will only select an algorithm that is usable by
all recipients. The most highly ranked digest algorithm in this list
is also used when signing without encryption (e.g. --clear-sign or
--sign).
And I see gpg --version in fact shows SHA1 as being included.
michael@bigbox ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, 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
I only have one key.
[michael@bigbox ~]$ gpg --list-keys
/home/michael/.gnupg/pubring.gpg
--------------------------------
pub 2048R/542342AE 2018-02-08
uid Michael Jones <tenthousandants@gmail.com>
sub 2048R/4D73CC3A 2018-02-08
And give it a try...
[michael@bigbox ~]$ gpg --edit-key 542342AE
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 2048R/542342AE created: 2018-02-08 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/4D73CC3A created: 2018-02-08 expires: never usage: E
[ultimate] (1). Michael Jones <tenthousandants@gmail.com>
gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)
Is SHA1 still there?
Note that the above referenced post Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:" states that one must adjust the personal-digest-preferences in $HOME/.gnupg/gpg.conf twice, so I am concerned that potentially there is something else which needs to be changes.
I don't think it matters, but I am running Centos7.
How do I prevent gpg from including SHA1?
gpg gnu hashsum signature
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
apt-get is complaining that signatures are invalid and that the InRelease file is not signed (see Using Centos to sign .deb packages for background). On the server, I have verified using gpg that InRelease is in fact signed.
Per Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:", one needs to do the following:
Adjust the personal-digest-preferences and personal-digest-preferences
in $HOME/.gnupg/gpg.conf to eliminate SHA-1 from one's GPG
preferences. This prevents the problem coming back with new keys.
Upon reviewing my reprepro setup, I have SHA1 shown under both the Release file (and the InRelease clearsign signature) and the individual Packages file, so I hope doing this will be successful.
~/.gnupg/gpg.conf seems to indicate that I will use hash algorithms as described by the default-preference-list, and then lists which ones to use first if available.
[michael@bigbox ~]$ cat ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512
man gpg states:
--personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg --version to get a list of available
algorithms, and use none to set no preference at all. This allows the
user to safely override the algorithm chosen by the recipient key
preferences, as GPG will only select an algorithm that is usable by
all recipients. The most highly ranked digest algorithm in this list
is also used when signing without encryption (e.g. --clear-sign or
--sign).
And I see gpg --version in fact shows SHA1 as being included.
michael@bigbox ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, 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
I only have one key.
[michael@bigbox ~]$ gpg --list-keys
/home/michael/.gnupg/pubring.gpg
--------------------------------
pub 2048R/542342AE 2018-02-08
uid Michael Jones <tenthousandants@gmail.com>
sub 2048R/4D73CC3A 2018-02-08
And give it a try...
[michael@bigbox ~]$ gpg --edit-key 542342AE
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 2048R/542342AE created: 2018-02-08 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/4D73CC3A created: 2018-02-08 expires: never usage: E
[ultimate] (1). Michael Jones <tenthousandants@gmail.com>
gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)
Is SHA1 still there?
Note that the above referenced post Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:" states that one must adjust the personal-digest-preferences in $HOME/.gnupg/gpg.conf twice, so I am concerned that potentially there is something else which needs to be changes.
I don't think it matters, but I am running Centos7.
How do I prevent gpg from including SHA1?
gpg gnu hashsum signature
apt-get is complaining that signatures are invalid and that the InRelease file is not signed (see Using Centos to sign .deb packages for background). On the server, I have verified using gpg that InRelease is in fact signed.
Per Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:", one needs to do the following:
Adjust the personal-digest-preferences and personal-digest-preferences
in $HOME/.gnupg/gpg.conf to eliminate SHA-1 from one's GPG
preferences. This prevents the problem coming back with new keys.
Upon reviewing my reprepro setup, I have SHA1 shown under both the Release file (and the InRelease clearsign signature) and the individual Packages file, so I hope doing this will be successful.
~/.gnupg/gpg.conf seems to indicate that I will use hash algorithms as described by the default-preference-list, and then lists which ones to use first if available.
[michael@bigbox ~]$ cat ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512
man gpg states:
--personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg --version to get a list of available
algorithms, and use none to set no preference at all. This allows the
user to safely override the algorithm chosen by the recipient key
preferences, as GPG will only select an algorithm that is usable by
all recipients. The most highly ranked digest algorithm in this list
is also used when signing without encryption (e.g. --clear-sign or
--sign).
And I see gpg --version in fact shows SHA1 as being included.
michael@bigbox ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, 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
I only have one key.
[michael@bigbox ~]$ gpg --list-keys
/home/michael/.gnupg/pubring.gpg
--------------------------------
pub 2048R/542342AE 2018-02-08
uid Michael Jones <tenthousandants@gmail.com>
sub 2048R/4D73CC3A 2018-02-08
And give it a try...
[michael@bigbox ~]$ gpg --edit-key 542342AE
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 2048R/542342AE created: 2018-02-08 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/4D73CC3A created: 2018-02-08 expires: never usage: E
[ultimate] (1). Michael Jones <tenthousandants@gmail.com>
gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)
Is SHA1 still there?
Note that the above referenced post Debian 9, APT, and "GPG error: ... InRelease: The following signatures were invalid:" states that one must adjust the personal-digest-preferences in $HOME/.gnupg/gpg.conf twice, so I am concerned that potentially there is something else which needs to be changes.
I don't think it matters, but I am running Centos7.
How do I prevent gpg from including SHA1?
gpg gnu hashsum signature
edited May 27 at 17:42
Jonas Stein
1,02721033
1,02721033
asked Feb 9 at 19:12
user1032531
518621
518621
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53
add a comment |Â
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choic
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disalow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfer with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperation with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choic
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disalow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfer with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperation with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
add a comment |Â
up vote
0
down vote
When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choic
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disalow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfer with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperation with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
add a comment |Â
up vote
0
down vote
up vote
0
down vote
When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choic
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disalow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfer with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperation with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choic
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disalow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfer with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperation with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
answered May 3 at 15:49
Ichthyo
1064
1064
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f423109%2fhow-do-i-prevent-gpg-from-including-sha1%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
You buried the fact that I made a typing error right at the bottom of this question. (-: My typing error is now corrected.
â JdeBP
Feb 10 at 8:05
@JdeBP Ah, the first mystery is solved! But the second remains. How does one eliminate SHA-1 from their digest and cipher GPG preferences?
â user1032531
Feb 10 at 10:53