Skip to content
This repository has been archived by the owner on Sep 6, 2022. It is now read-only.

add a key expansion function #131

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

add a key expansion function #131

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 15 additions & 0 deletions crypto/key.go
View file
Open in desktop
Expand Up @@ -20,6 +20,7 @@ import (

"github.com/gogo/protobuf/proto"
sha256 "github.com/minio/sha256-simd"
"golang.org/x/crypto/hkdf"
)

const (
Expand Down Expand Up @@ -174,6 +175,20 @@ func GenerateEKeyPair(curveName string) ([]byte, GenSharedKey, error) {
return pubKey, done, nil
}

// ExpandKey expands the private key k to a key of length l using the info.
func ExpandKey(k PrivKey, info []byte, l int) ([]byte, error) {
raw, err := k.Raw()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDK if using raw bytes of arbitrary asymmetric encryption private key is the right thing to do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually like to add this to the private key interface so keys can choose how to implement this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it makes sense. For example DH keys could implement it via DH with static, well-known key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually like to add this to the private key interface so keys can choose how to implement this.

Isn't the whole point of using a HKDF here to guarantee a secure key derivation, which doesn't depend on the source and the structure of the randomness used as an input (as long as this random data has high enough entropy, which is basically the definition of what a private key is)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, after sleeping on it, it is non-blocker to use raw bytes of private key for HKDF, only issue might be consequences of it, as all implementations would have to implement the same raw encoding of these keys for the key to be portable.

AFAIK key being portable is not a requirement for QUIC but it might be useful for something else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, what I'd like to do is both:

  1. Provide a helper function for deriving a key from bytes.
  2. Add a function to the private key interfaces for deriving keys.

Most implementations will just call the helper function. However, implementations may choose to do something different based on the key type. For example, ed25519 keys are already uniformly random, as far as I know, so they can skip the first step.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you shouldn't skip the HKDF even when using ed25519 as it is important step in protecting the key itself.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two steps: Extract and Expand. See: https://tools.ietf.org/html/rfc5869#section-3.3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, what I'd like to do is both:

  1. Provide a helper function for deriving a key from bytes.
  2. Add a function to the private key interfaces for deriving keys.

We need to think about interoperability here. While it doesn't matter for the stateless reset case that triggered this issue, if we ever want to use this for deriving a symmetric encryption key between two peers (I was considering a design like that for the QUIC protector), we need to specify how keys are derived.

Alright, after sleeping on it, it is non-blocker to use raw bytes of private key for HKDF, only issue might be consequences of it, as all implementations would have to implement the same raw encoding of these keys for the key to be portable.

Can we, instead of using the raw bytes of the private key, use the key to encrypt a constant message (e.g. 32 zero-bytes), and use that as the pseudorandom input for the HKDF?

if err != nil {
return nil, err
}
b := make([]byte, l)
r := hkdf.New(sha256.New, raw, nil, info)
if _, err := io.ReadFull(r, b); err != nil {
return nil, err
}
return b, nil
}

// StretchedKeys ...
type StretchedKeys struct {
IV []byte
Expand Down
14 changes: 14 additions & 0 deletions crypto/key_test.go
View file
Open in desktop
Expand Up @@ -355,3 +355,17 @@ func TestPanicOnUnknownCipherType(t *testing.T) {
passed = true
KeyStretcher("Fooba", "SHA1", []byte("foo"))
}

func TestKeyExpansion(t *testing.T) {
priv, _, err := GenerateECDSAKeyPair(rand.Reader)
if err != nil {
t.Fatalf("err generating key:%v", err)
}
expanded, err := ExpandKey(priv, []byte("info"), 42)
if err != nil {
t.Fatalf("error expanding key: %v", err)
}
if len(expanded) != 42 {
t.Fatalf("unexpected expanded key length: %d", len(expanded))
}
}
1 change: 1 addition & 0 deletions go.mod
View file
Open in desktop
Expand Up @@ -15,6 +15,7 @@ require (
github.com/multiformats/go-multihash v0.0.13
github.com/multiformats/go-varint v0.0.5
go.opencensus.io v0.22.3
golang.org/x/crypto v0.0.0-20190611184440-5c40567a22f8
)

go 1.13