nspcc-dev/neofs-rest-gw

Fork 0

mirror of https://github.com/nspcc-dev/neofs-rest-gw.git synced 2026-03-01 04:29:14 +00:00

Define what we expect to sign #6

New issue

Closed

opened 2025-12-28 17:59:49 +00:00 by sami · 6 comments

sami commented

2025-12-28 17:59:49 +00:00

Owner

Originally created by @alexvanin on GitHub (Jun 14, 2022).

/auth returns base64 encoded token, e.g. ChB0+OQbVaBLGYnzPP89IXQUEhsKGTVxfQ56a0uQeFmOO63mqykBS1HNpw1rxSgaBgiPAxirAiIhAnLj82Qmdlcg7JtoyhDjJ1OsRFjtmxdXbzrwVkwxWAdWMgQIARAB.

WalletConnect expects to sign text string. So the easiest way is to sign this base64 string.

However, gateway and neofs-node now expect signature of binary encoded token. In this case web application should convert base64 => bytes, bytes => string, sign string.

In this issue: double check expected signed value and decide if this scheme should stay or be reworked.

/cc @KirillovDenis @realloc @mike-petrov @masterSplinter01 @fyrchik

Originally created by @alexvanin on GitHub (Jun 14, 2022). `/auth` returns base64 encoded token, e.g. `ChB0+OQbVaBLGYnzPP89IXQUEhsKGTVxfQ56a0uQeFmOO63mqykBS1HNpw1rxSgaBgiPAxirAiIhAnLj82Qmdlcg7JtoyhDjJ1OsRFjtmxdXbzrwVkwxWAdWMgQIARAB`. WalletConnect expects to sign text string. So the easiest way is to sign this base64 string. However, gateway and neofs-node now expect signature of binary encoded token. In this case web application should convert base64 => bytes, bytes => string, sign string. In this issue: double check expected signed value and decide if this scheme should stay or be reworked. /cc @KirillovDenis @realloc @mike-petrov @masterSplinter01 @fyrchik

sami

2025-12-28 17:59:49 +00:00

closed this issue
added the
question
label

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@alexvanin commented on GitHub (Jun 15, 2022):

From the front end side, signing string formatted binary messages looks really ugly. Some wallets may hide signing message details, but some don't. Signing binary encoded bearer token looks like this:

Base64 encoded token will be at least readable.

@alexvanin commented on GitHub (Jun 15, 2022): From the front end side, signing string formatted binary messages looks really ugly. Some wallets may hide signing message details, but some don't. Signing binary encoded bearer token looks like this: ![image](https://user-images.githubusercontent.com/6323066/173779671-571d0b4d-e0bf-48e3-a8d5-542b4290fa98.png) Base64 encoded token will be at least readable.

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@fyrchik commented on GitHub (Jun 15, 2022):

I think this is a client issue. Can we have multiple views for signed data? Like this:

if it is UTF-8, output text
if it can be unmarshaled as a bearer token, pretty-print it's fields
Just output binary data otherwise

As I understand the only problem here is working with protobuf on the javascript side, right?

@fyrchik commented on GitHub (Jun 15, 2022): I think this is a client issue. Can we have multiple views for signed data? Like this: 1. if it is UTF-8, output text 2. if it can be unmarshaled as a bearer token, pretty-print it's fields 3. Just output binary data otherwise As I understand the only problem here is working with protobuf on the javascript side, right?

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@alexvanin commented on GitHub (Jun 15, 2022):

I think this is a client issue.

This is more like Wallet Connect SDK issue. It allows to sign only strings. Therefore wallet clients, like aero wallet in example above, just prints this string without encoding because, well, it is already a string. Neither front end nor REST Gateway are in control of this output, it is a wallet output.

Since NeoFS wants to provide additional signature type to work specifically with wallet connect, maybe it makes sense to expect signature of string encoded binary data instead of signature of binary data? That's the question I want to discuss there.

@alexvanin commented on GitHub (Jun 15, 2022): > I think this is a client issue. This is more like Wallet Connect SDK issue. It allows to sign only strings. Therefore wallet clients, like aero wallet in example above, just prints this string without encoding because, well, it is already a string. Neither front end nor REST Gateway are in control of this output, it is a wallet output. Since NeoFS wants to provide additional signature type to work _specifically_ with wallet connect, maybe it makes sense to expect signature of _string encoded binary data_ instead of signature of _binary data_? That's the question I want to discuss there.

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@alexvanin commented on GitHub (Jun 16, 2022):

With @mike-petrov we successfully built web app which signs base64 encoded token and REST GW + NeoFS Node use base64 in Sign/Verify routines. We still have issues with signing binary encoded token, though.

// neofs-api-go
func verify(cfg *cfg, data []byte, sig *refs.Signature) error {
	// ...
	switch cfg.scheme {
	// ...
	case refs.ECDSA_RFC6979_SHA256_WALLET_CONNECT:
		s := base64.StdEncoding.EncodeToString(data)
		if !walletconnect.Verify(pub, []byte(s), sig.GetSign()) {
			return crypto.ErrInvalidSignature
		}
		return nil
	// ...
	}
}

func sign(cfg *cfg, key *ecdsa.PrivateKey, data []byte) ([]byte, error) {
	switch cfg.scheme {
	// ...
	case refs.ECDSA_RFC6979_SHA256_WALLET_CONNECT:
		s := base64.StdEncoding.EncodeToString(data)
		return walletconnect.Sign(key, []byte(s))
	// ...
	}
}

@alexvanin commented on GitHub (Jun 16, 2022): With @mike-petrov we successfully built web app which signs base64 encoded token and REST GW + NeoFS Node use base64 in `Sign/Verify` routines. We still have issues with signing binary encoded token, though. ```go // neofs-api-go func verify(cfg *cfg, data []byte, sig *refs.Signature) error { // ... switch cfg.scheme { // ... case refs.ECDSA_RFC6979_SHA256_WALLET_CONNECT: s := base64.StdEncoding.EncodeToString(data) if !walletconnect.Verify(pub, []byte(s), sig.GetSign()) { return crypto.ErrInvalidSignature } return nil // ... } } func sign(cfg *cfg, key *ecdsa.PrivateKey, data []byte) ([]byte, error) { switch cfg.scheme { // ... case refs.ECDSA_RFC6979_SHA256_WALLET_CONNECT: s := base64.StdEncoding.EncodeToString(data) return walletconnect.Sign(key, []byte(s)) // ... } } ```

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@alexvanin commented on GitHub (Jun 16, 2022):

After internal meeting we've decided to sign base64 encoded values instead of binary values. I will close this issue when we check that it works fine with all REST Gateway methods.

@alexvanin commented on GitHub (Jun 16, 2022): After internal meeting we've decided to sign base64 encoded values instead of binary values. I will close this issue when we check that it works fine with all REST Gateway methods.

sami commented

2025-12-28 17:59:50 +00:00

Author

Owner

@alexvanin commented on GitHub (Jun 22, 2022):

NeoFS is going to sign and verify base64 encoded strings of binary data for wallet connect. See:

Closed.

@alexvanin commented on GitHub (Jun 22, 2022): NeoFS is going to sign and verify base64 encoded strings of binary data for wallet connect. See: - https://github.com/nspcc-dev/neofs-api/pull/206 - https://github.com/nspcc-dev/neofs-api-go/pull/386 - https://github.com/nspcc-dev/neofs-sdk-go/pull/274 Closed.