Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
Hi, On Sat, 4 Aug 2018 07:29:47 -0700 Hanno Böck wrote: > > Symmetric cryptography is quite conservative and it took years and > > even decades for algorithms and their implementations to become > > trusted, so there is nothing wrong in using good old verified > > software. > > When it comes to cipher modes the fact that people use decades old > modes is a problem. See efail for a prominent example, but there > are many less prominent ones. > > Look at the mcrypt webpage: > http://mcrypt.sourceforge.net/ > > Modes of Operation: > > CBC > CFB > CTR > ECB > OFB > NCFB > > That is a mixture of very insecure (ECB), insecure in most situations > (all others) and totally obscure modes. It doesn't include any > authenticated encryption modes, which in most situations is what you > want to use. I want to use mcrypt for local encryption only, therefore I don't really care about MACs. In my use cases modification tampering is easy to detect by other means. ECB is indeed unsafe and must be avoided (hey, openssl supports ECB as well, let's ban it!). CBC is better, but vulnerable to PODDLE, so I agree on avoiding it as well. As for CTR, (N)CFB, (N)OFB there is nothing obscure about them: they are known for decades and are well studied. There are no direct attacks on these modes known aside from detectable tampering possibility. Best regards, Andrew Savchenko pgpOpfRZo6zw5.pgp Description: PGP signature
[gentoo-dev] Last rites: sys-apps/microcode-ctl
# Thomas Deutschmann (05 Aug 2018) # Deprecated. Using recent microcodes with this package either won't work # or crash your system. Please change your setup and make use of kernel's # early microcode loading feature, see https://wiki.gentoo.org/wiki/Microcode # for more details. Removal in 30 days. sys-apps/microcode-ctl -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part
W dniu sob, 04.08.2018 o godzinie 14∶34 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Sat, 4 Aug 2018, Michał Górny wrote: > > GLEP 63 originally did not include a rationale. Given the importance > > of this document, I think it would be reasonable to include one and > > use the opportunity to explain the policies in detail. > > The council just approved the updated GLEP 63 in its July meeting. > > So this should either have been submitted as part of that update, or > you should at least have given notice to the council that further > changes are pending (as you were present during the meeting). In the > latter case, we may likely have postponed the decision about the GLEP > update, which wasn't entirely uncontroversial. > This wasn't planned. I was writing a blog post yesterday, and it occurred to me that I could extend it into the rationale for this GLEP. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
On Sat, 4 Aug 2018 13:05:56 -0500 Marty E. Plummer wrote: [...] > It seems that every last person commenting on this is talking mcrypt, > not mhash, which is what I mentioned in the first place. As far as I can > tell, these are entirely differnt projects which just happen to have a > similar name. Yes, they are. But it this very case I'm interested in mcrypt status, not mhash, that's why I changed the subject field of this discussion. Best regards, Andrew Savchenko pgpZBs6CP4JXU.pgp Description: PGP signature
Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
On Sat, Aug 04, 2018 at 11:43:28AM +0300, Andrew Savchenko wrote: > On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote: > > On Fri, 22 Jun 2018 21:50:50 -0500 > > "Marty E. Plummer" wrote: > > > > > So, as you may be aware I've been doing some work on moving bzip2 to > > > an autotools based build. Recently I've ran into app-crypt/mhash, > > > which is in a semi-abandoned state (talking with the maintainer on > > > twitter atm), and I was thinking it may be a good idea to set up a > > > project for keeping these semi-abandoned and really-abandoned > > > libraries and projects up to date and such. > > > > This is a common problem, however if you want to make this reasonable > > you wouldn't make it a gentoo thing, but a cross-distro effort. The > > idea has been tossed around a lot, but noone yet started implementing > > it. > > > > However keeping things alive may not always be the right option. > > There's a reason mcrypt is abandoned. It's an ancient crypto library, > > crypto is moving forward, there are better options. > > Do you have any evidence that mcrypt should not be used? > > Symmetric cryptography is quite conservative and it took years and > even decades for algorithms and their implementations to become > trusted, so there is nothing wrong in using good old verified > software. > > Actually for local symmetric encryption this is the best tool I > know. > > Best regards, > Andrew Savchenko It seems that every last person commenting on this is talking mcrypt, not mhash, which is what I mentioned in the first place. As far as I can tell, these are entirely differnt projects which just happen to have a similar name.
Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
On 2018-08-04 16:29, Hanno Böck wrote: >> Do you have any evidence that mcrypt should not be used? > Well, PHP was as far as I'm aware its main user and PHP has declared > mcrypt support to be deprecated a while ago. In all fairness: Yes, PHP project has removed ext/mcrypt from core, but they only moved it into an own PECL extension. My point here is, that they did not drop and prune mcrypt from universe due to security vulnerabilities. Anyone interested in this should read the following posting [1]. tl;dr Like most crypto libs, mcrypt isn't easy to use and you will likely do something wrong. In favor of a better solutions which should prevent such a misuse, mcrypt was deprecated. See also: = [1] https://why-cant-we-have-nice-things.mwl.be/requests/deprecate-then-remove-mcrypt. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part
On 2018-08-04 14:34, Ulrich Mueller wrote: > So this should either have been submitted as part of that update, or > you should at least have given notice to the council that further > changes are pending (as you were present during the meeting). In the > latter case, we may likely have postponed the decision about the GLEP > update, which wasn't entirely uncontroversial. I agree but nevertheless I appreciate that someone (Michał in this case) doesn't rest and continue to improve things. Michał Górny wrote: > +Furthermore, the specification requires separate subkeys for different > +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to > +using a separate encryption key) aiming to further reduce the attack surface. > +Kristian Fiskerstrand points out e.g. it is technically possible to obtain > +a valid signature over crafted data while using the subkey for purposes > +of authorization [#COUNCIL-MEETING-20180729]_. I challenge this one: If an attacker is already able to trick a developer into signing something the developer didn't want to sign, the same attacker will also be able to trick the same developer into using the right sub key the attacker is actually interested in. My point is: While I don't disagree that best practice should be an own sub key for every purpose, arguing that this has an impact on security is wrong. And that was and still is my reason why I don't want that this is getting enforced. Michał Górny wrote: > +This policy serves two purposes. Firstly, it provides a last fallback option > +in the event of access to the secret keys being lost and there being > +no possibility of revoking them. In this case, the keys eventually expire > +and users can clearly see that they are no longer being used. Secondly, it > +ensures that the developers periodically confirm their access to the primary > +key. And I am also challenging this one: Given that this a policy for Gentoo, we have to take Gentoo specifics into account: In Gentoo the primary purpose of OpenGPG is to sign commits and push operations. A git hook ensures that each commit and push is well signed by a known key. However, this key is coming from Gentoo's LDAP. LDAP is accessed via SSH key. So anyone with access to a developer's SSH key is able to add an additional (malicious) key which would be picked up by other automated processes with the result that whoever is in control of that additional key could now use it to commit and push to any Gentoo repositories. In this process, an expiration date isn't really used. Again, it is best practice but when we don't use it, why do we care and enforce such a value? Well, if you take the *now* proposed "Foreword" into account I *could* arrange with such a statement because expiration date plays a role in the web of trust and GLEP 63 seems to be more than just a OpenGPG policy for commit/push. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
Hi, On Sat, 4 Aug 2018 11:43:28 +0300 Andrew Savchenko wrote: > Do you have any evidence that mcrypt should not be used? Well, PHP was as far as I'm aware its main user and PHP has declared mcrypt support to be deprecated a while ago. > Symmetric cryptography is quite conservative and it took years and > even decades for algorithms and their implementations to become > trusted, so there is nothing wrong in using good old verified > software. When it comes to cipher modes the fact that people use decades old modes is a problem. See efail for a prominent example, but there are many less prominent ones. Look at the mcrypt webpage: http://mcrypt.sourceforge.net/ Modes of Operation: CBC CFB CTR ECB OFB NCFB That is a mixture of very insecure (ECB), insecure in most situations (all others) and totally obscure modes. It doesn't include any authenticated encryption modes, which in most situations is what you want to use. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgpVU0M0tWo7W.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part
> On Sat, 4 Aug 2018, Michał Górny wrote: > GLEP 63 originally did not include a rationale. Given the importance > of this document, I think it would be reasonable to include one and > use the opportunity to explain the policies in detail. The council just approved the updated GLEP 63 in its July meeting. So this should either have been submitted as part of that update, or you should at least have given notice to the council that further changes are pending (as you were present during the meeting). In the latter case, we may likely have postponed the decision about the GLEP update, which wasn't entirely uncontroversial. Ulrich
Re: [gentoo-dev] Re: mcrypt status
On Sat, 4 Aug 2018 09:51:14 + (UTC) Martin Vaeth wrote: > Andrew Savchenko wrote: > > > > Actually for local symmetric encryption this is the best tool I > > know. > > What is the advantage over gpg --symmetric? 1) mcrypt has wider range of algorithms, including gost which I need. 2) gpg-agent sometimes causes too much trouble (by being enforced in gpg2) and I like it more to enter passphares without any agents. xterm can grab screen and that is sufficient for my needs. Other than that gpg -s in nice and good tool. Best regards, Andrew Savchenko pgpwFLuH6LfnQ.pgp Description: PGP signature
[gentoo-dev] Re: mcrypt status
Andrew Savchenko wrote: > > Actually for local symmetric encryption this is the best tool I > know. What is the advantage over gpg --symmetric?
mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)
On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote: > On Fri, 22 Jun 2018 21:50:50 -0500 > "Marty E. Plummer" wrote: > > > So, as you may be aware I've been doing some work on moving bzip2 to > > an autotools based build. Recently I've ran into app-crypt/mhash, > > which is in a semi-abandoned state (talking with the maintainer on > > twitter atm), and I was thinking it may be a good idea to set up a > > project for keeping these semi-abandoned and really-abandoned > > libraries and projects up to date and such. > > This is a common problem, however if you want to make this reasonable > you wouldn't make it a gentoo thing, but a cross-distro effort. The > idea has been tossed around a lot, but noone yet started implementing > it. > > However keeping things alive may not always be the right option. > There's a reason mcrypt is abandoned. It's an ancient crypto library, > crypto is moving forward, there are better options. Do you have any evidence that mcrypt should not be used? Symmetric cryptography is quite conservative and it took years and even decades for algorithms and their implementations to become trusted, so there is nothing wrong in using good old verified software. Actually for local symmetric encryption this is the best tool I know. Best regards, Andrew Savchenko pgpwPymO8y5c2.pgp Description: PGP signature
[gentoo-dev] [PATCH 2/3] glep-0063: Reorder references to match document order
--- glep-0063.rst | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index c783910..e40ddd3 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -160,12 +160,6 @@ References .. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096? (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096) -.. [#DEBIANGPG] Debian GPG documentation - (https://wiki.debian.org/Keysigning) - -.. [#RISEUP] RiseUp.net OpenPGP best practices - (https://help.riseup.net/en/security/message-security/openpgp/best-practices) - .. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest (http://devmanual.gentoo.org/general-concepts/manifest/index.html) @@ -180,6 +174,12 @@ References Part 2: Best Practices for Key Management Organization (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf) +.. [#DEBIANGPG] Debian GPG documentation + (https://wiki.debian.org/Keysigning) + +.. [#RISEUP] RiseUp.net OpenPGP best practices + (https://help.riseup.net/en/security/message-security/openpgp/best-practices) + .. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report, 2013 recommendations, version 1.0 (October 2013) (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report) -- 2.18.0
[gentoo-dev] [PATCH 3/3] glep-0063: Include a rationale
--- glep-0063.rst | 129 ++ 1 file changed, 129 insertions(+) diff --git a/glep-0063.rst b/glep-0063.rst index e40ddd3..cab52b0 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -132,6 +132,122 @@ of the fingerprint field. In any place that presently displays the "``gpgkey``" field, the last 16 hex digits of the fingerprint should be displayed instead. +Rationale += + +Foreword + + +This policy aims to provide a good set of OpenPGP usage policies both +to protect Gentoo resources from unauthorized access and to protect developer +identities from being spoofed. The former is significant since it could +be used to deliver malicious content to Gentoo users; the latter because +it could be used to damage the reputation of Gentoo. + +Separate signing subkey +--- + +The specification requires that a separate subkey is used for signing. This +is a subset of more general recommendation of using the primary key only for +the purpose of important key operations and storing it offline, while using +separate subkeys for day-to-day operations. + +The main purpose of this is to reduce the attack surface. By reducing the use +of primary key and keeping it offline, the risk of attacks against it is +reduced. If the attacker manages to compromise the developer's keyring, only +subkeys are compromised and the developer can revoke them without having +the whole key compromised. + +Furthermore, the specification requires separate subkeys for different +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to +using a separate encryption key) aiming to further reduce the attack surface. +Kristian Fiskerstrand points out e.g. it is technically possible to obtain +a valid signature over crafted data while using the subkey for purposes +of authorization [#COUNCIL-MEETING-20180729]_. + +Revocation certificate +-- + +The specification recommends the best practice of storing a copy +of the revocation certificate off site. A common recommendation is to have +the ASCII-armored version of the certificate printed on paper, to protect +against hardware failures (but beware that print servers may store a copy +of the data!). + +The goal of the revocation certificate is to provide the developer with +ability to revoke the key in case the access to it is lost, e.g. due to +hardware damage combined with lack of backups, major events resulting +in backups being destroyed as well, or more importantly in the event +of hardware being stolen or lost. + +Key algorithm and length + + +The choice of key algorithm and length defines the resistance of the key +against brute-force attacks. + +Originally, the specification permitted using DSA keys. However, there is no +compelling reason to continue using DSA. According to the GnuPG FAQ, RSA has +much wider support in smart-card solutions [#GNUPG-FAQ-11-1]_. Furthermore, +the RFC 4880bis draft removes the requirement of DSA support in clients favor +of obligatory RSA (and ECDSA) support [#RFC4880bis]_. + +The RSA algorithm is recommended as it is considered secure at the moment +and provides for the best interoperability. The 2048-bit key length +is considered sufficiently secure for all our uses. Historically, this +specification recommended 4096-bit keys. However, while longer keys are still +permitted, they are no longer recommended as they give little in regards +to security, yet are capable of causing performance problems, especially +when using external hardware [#GNUPG-FAQ-11-4]_. + +Additionally, elliptic curve algorithms using Curve 25519 are allowed. +However, they are not recommended due to compatibility concerns +(in particular, not being supported by GnuPG prior to 2.1). +The remaining curves supported by GnuPG (and appropriately listed +in RFC 4880bis draft) are not allowed since there are concerns about safety +of those curves [#SAFECURVES]_. + +Key expiration +-- + +It is important to note that the expiration dates as required by this +specification are not to be conflated with key rotation. This specification +does not enforce any specific key rotation scheme; expiration serves purely +the purpose of requiring periodic prolongation. + +This policy serves two purposes. Firstly, it provides a last fallback option +in the event of access to the secret keys being lost and there being +no possibility of revoking them. In this case, the keys eventually expire +and users can clearly see that they are no longer being used. Secondly, it +ensures that the developers periodically confirm their access to the primary +key. + +The expiration period has been chosen as a matter of compromise between being +secure and causing major trouble to developers keeping keys in secure vaults. +The period of 900 days represents the baseline of 2 years with roughly half +a year grace period for extending the expiration date early. Speci
[gentoo-dev] [PATCH 1/3] glep-0063: Remove unused references
--- glep-0063.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 64fb437..c783910 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -163,9 +163,6 @@ References .. [#DEBIANGPG] Debian GPG documentation (https://wiki.debian.org/Keysigning) -.. [#EKAIA] Ana's blog: Creating a new GPG key - (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/) - .. [#RISEUP] RiseUp.net OpenPGP best practices (https://help.riseup.net/en/security/message-security/openpgp/best-practices) @@ -183,10 +180,6 @@ References Part 2: Best Practices for Key Management Organization (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf) -.. [#ISSUER-ANNOTATE] Including the entire fingerprint of the issuer - in an OpenPGP certification - (http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) - .. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report, 2013 recommendations, version 1.0 (October 2013) (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report) -- 2.18.0
[gentoo-dev] [PATCH 0/3] GLEP 63: rationale part
Hi, GLEP 63 originally did not include a rationale. Given the importance of this document, I think it would be reasonable to include one and use the opportunity to explain the policies in detail. -- Best regards, Michał Górny Michał Górny (3): glep-0063: Remove unused references glep-0063: Reorder references to match document order glep-0063: Include a rationale glep-0063.rst | 140 ++ 1 file changed, 131 insertions(+), 9 deletions(-) -- 2.18.0
