Cannot reproduce EdDSA signature

[idcmp]

Hello! This may be more of a discussion as it's not technically a bug (or maybe it is?).

For CI/CD reasons I'm attempting to reproduce the work that sign_update does, but I'm not able to successfully reproduce the same signature. I was wondering if there's anything special about what Sparkle does to calculate the signature?

sign_update (2.3.0)

$ export sparklekey=M...Mv
$ sign_update -s "$sparklekey" /tmp/testdata
Warning: The -s option for passing the private EdDSA key is insecure and deprecated. Please see its help usage for more information.
sparkle:edSignature="vViaNW5HGasfuVY7pm2aubC7Q2IHCp+BjY0/cuaYlFwTmL7vqtZFqfXnSK00oAx5YdyRXA5QQDxWu9K2TmWFDg==" length="24119925"

My test example

Using

Sparkle/sign_update/main.swift

Line 71 in a208bd5

func edSignature(data: Data, publicEdKey: Data, privateEdKey: Data) -> String {

for reference.

# same sparklekey value
$ go run .
sparkle:edSignature="WNSAvnHmKJRY4pYYM+5hUfH5mNkR8y0kAWQUsyY7n+gUErENCrNJjLBQQbXoYRtP1nF+ZP5qJioeJE1JYN4cBA==" length=24119925

Example Go Source

package main

import (
	"crypto/ed25519"
	"encoding/base64"
	"fmt"
	"os"
)

func main() {

        // decode the key used for signing
	sparkleKeyBytes, err := base64.StdEncoding.DecodeString(os.Getenv("sparklekey"))
	if err != nil {
		panic(err)
	}
	if len(sparkleKeyBytes) != 96 {
		panic("sparkleKeyBytes != 96")
	}

        // split it, just like the Swift code does
	sparklePrivateBytes := sparkleKeyBytes[:64]
	sparklePublicBytes := sparkleKeyBytes[64:]

	if len(sparklePublicBytes) != 32 || len(sparklePrivateBytes) != 64 {
		panic("sparkle private/public key bytes incorrect length")
	}

        // read in the test file
	fileBytes, err := os.ReadFile("/tmp/testdata")
	if err != nil {
		panic(fmt.Sprintf("could not read testdata: %s", err))
	}

        // and sign it
	signature := ed25519.Sign(sparklePrivateBytes, fileBytes)
	if len(signature) != 64 {
		panic("sparkle signature not 64 bytes")
	}

        // convert the signature to base64
	sig := base64.StdEncoding.EncodeToString(signature)
	fmt.Printf("sparkle:edSignature=%q length=%d\n", sig, len(fileBytes))

}

I've tried with a few different libraries now and I get results congruent across libraries, but none match what sign_update give me. Is there some extra special magic going on? Do you have other tools that can reproduce the output of sign_update?

[zorgiepoo]

See #2160 and the library we use https://github.com/orlp/ed25519 (particularly notes in Usage section)

By the way, the -s option to sign_update is deprecated due to #2168

[idcmp]

Oh perfect! I'll try a standalone integration with that and let you know.

[idcmp]

Well, I've reproduced this standalone with orip/ed25519 and Go's ed25519. I'll keep looking for a bit.

[idcmp]

The project looks like it's unmaintained, but I've filed an issue there for now and will use sign_update in the interim.

( orlp/ed25519#37 )

[zorgiepoo]

That is probably just going to get closed or duped to orlp/ed25519#10 or any of the other issues people have filed about..

[idcmp]

Oh! I didn't think to look for closed issues.

[idcmp]

@zorgiepoo Am I correct in guessing the key stored in Keychain is base64 encoded version of an orip/ed25519 private key?

[zorgiepoo]

Looking at the code, it looks likes a concatenation of the private + public key that orip/ed25519 uses (encoded as base64).

[idcmp]

Solved. I generate a ed25519 key inside Go:

	pubKey, privKey, err := ed25519.GenerateKey(rand.Reader)

I use the example code from the issue you linked to convert the Go private key to a lib private key:

func privKeyToLibPrivKey(privKeyIn []byte) []byte {
	hash := sha512.New()
	hash.Write(privKeyIn[:32])
	hashBytes := hash.Sum(nil)

	hashBytes[0] &= 248
	hashBytes[31] &= 63
	hashBytes[31] |= 64

	return hashBytes
}

To make a Sparkle key:

	libPrivKey := privKeyToLibPrivKey(privKey)
	sparkleKeyBytes := append(libPrivKey, pubKey...) // append regular public key
	sparkleKey := base64.StdEncoding.EncodeToString(sparkleKey) // use StdEncoding to pad output

I pass libPrivKey into the privBuf above and my call to the library works. I pass the base64 encoded key (sparkleKey) to sign_update and I get matching signatures:

ed25519.Sign -> "1jSKA1IOu68b3+jTMEiDkQ2E5tb1YfncCrhjMzDYJcaAgAVfnCbE58ADbcpY0j4jgYr9s00TeeZyoMmVRSWdDA=="
sparklekey="8JMti8PLCY/WfLkIgTo703ZbjuFaP3kEjPOIk9Tg8kSOF2gSo7nDlrADMDQseSrkU1G1p6nCG+U7WxpNHO0ZQSNN3N0lTQZZQ00LArBdXQO/gGSLb6EjC9h7JaRkzk9p"
C.ed25519_sign -> "1jSKA1IOu68b3+jTMEiDkQ2E5tb1YfncCrhjMzDYJcaAgAVfnCbE58ADbcpY0j4jgYr9s00TeeZyoMmVRSWdDA=="

When I pass sparklekey into sign_update:

sparkle:edSignature="1jSKA1IOu68b3+jTMEiDkQ2E5tb1YfncCrhjMzDYJcaAgAVfnCbE58ADbcpY0j4jgYr9s00TeeZyoMmVRSWdDA==" length="10000"

Unfortunately I've already released an update with an existing EdDSA key pair, so I can't switch over to using this (without appcast monkeying), but hopefully it helps someone.

[zorgiepoo]

Cool that you figured it out (I haven't deeply verified the logic but I think it makes sense). Note Sparkle does support rotating keys if your updates are signed with the same Apple developer ID and you're updating a regular app bundle (not a pkg). Edit: actually you could still change your keys if you ship pkg for the new bundle.

[zorgiepoo]

We'll be making interoperability easier for new generated keys going forward in #2472