Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: crypto/x509: support extending list of algorithms #34844

Closed
denisvolin opened this issue Oct 11, 2019 · 4 comments
Closed

proposal: crypto/x509: support extending list of algorithms #34844

denisvolin opened this issue Oct 11, 2019 · 4 comments
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone
Proposal

Comments

@denisvolin
Copy link

denisvolin commented Oct 11, 2019 •
edited

What version of Go are you using (go version)?

-- go1.12.4

Does this issue reproduce with the latest release?

-- Probably, yes too.

What operating system and processor architecture are you using (go env)?

-- Linux, amd64

What did you do?

Used a test.cer file which contains encoded pkix certificate using GOST 34.10-2001 algorithm
and attempted to extract the name with:

package main

import (
      "io"
      "os"
      dio "custom/package"
)

func main() {
	file, err := os.Open("test.cer")
	if err != nil {
		fmt.Println("file opening error:", err)
		return
	}

	defer file.Close() //nolint:errcheck

	data, err := dio.ReadOut(file) // reads out the io.Reader until an error
	if err != nil && err != io.EOF {
		fmt.Println("file reading error:", err)
		return
	}

	cert, err := x509.ParseCertificate(data)
	if err != nil {
		fmt.Println("error on parsing:", err)
	} else {
		fmt.Println(cert.PublicKeyAlgorithm)
        }
}

What did you expect to see?

Some name, for example GOST 34.10-2001.

What did you see instead?

0

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason, as stated by the contributor, Adam Langley: not carrying it's weight, ― obsolete, in my opinion.

I suggest that package x509 at very least should support extending the list of the supported algorithms defining a way to extend the x509 package with external packages, the same way image package can be extended. Which essentially means, that the whole crypto package and specifically it's hash sub-package, both need to adopt the same changes.

After all new algorithms are popping out, old become vulnerable and thus obsolete, some countries, e.g. China, India, Israel, Russia, ― are defining cryptography algorithms out of the default, so far, range. In my opinion, packages crypto, crypto/hash and crypto/x509 need to allow the user to extend the usage, allowing other implementations to comply with the unified interface, skipping the necessity to comply only with crypto package by redefining the whole x509 from the scratch.
@gopherbot gopherbot added this to the Proposal milestone Oct 11, 2019
@zx2c4
Copy link
Contributor

zx2c4 commented Oct 11, 2019

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason,

The Linux kernel crypto people will accept anything. Not sure their judgement is super relevant.

@denisvolin
Copy link
Author

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason,

The Linux kernel crypto people will accept anything. Not sure their judgement is super relevant.

I can't argue about the crypto people, the point is that the algorithms out of the supported by the crypto/hash and thus crypto/x509 range are making their way into kernels, TSL/SSL libraries and even browsers (derivatives of Chromium and FF, to be specific), which makes them not that lightweight as it seems.

Keeping the list of supported hash functions and algorithms restricted seems like an outdated solution, it's not 80-x or 90-s anymore when everyone used mostly a limited variety of applicable technology.

Go is nowadays used in many countries in production, and thus limiting the supported range of cryptography makes people choose to use Go in partial implementation, leaving the main role to some other languages, which do not apply such restrictions. I do understand, that developers are free to implement the support in a custom solution. Yet, I think, that providing an extendable interface is a more flexible approach.

@ianlancetaylor ianlancetaylor changed the title Proposal: rewamping crypto, hash and x509 packages proposal: crypto/x509: support extending list of algorithms Oct 11, 2019
@ianlancetaylor ianlancetaylor added the Proposal-Crypto Proposal related to crypto packages or other security issues label Oct 11, 2019
@ianlancetaylor
Copy link
Contributor

CC @FiloSottile @agl

@FiloSottile
Copy link
Contributor

We did not argue that the functions are weak. We argued that supporting them is not worth the complexity and the resources required to maintain a secure and fast implementation. Linux adding an implementation does not change the fact that they are rarely used.

We disagree about how modern cryptography has developed. I strongly believe that modern cryptography has fewer, not more, options. Modern cryptography is picking the best primitive for the job, and only supporting that. Extensibility in security contexts is an anti-pattern, it adds risk and complexity, and delegated decisions to users that don't need or want to make them. You can read more about the decision framework for this at https://golang.org/design/cryptography-principles.

@golang golang locked and limited conversation to collaborators Oct 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
5 participants
@zx2c4 @FiloSottile @ianlancetaylor @gopherbot @denisvolin