0
$\begingroup$

I need to sign a URL to make sure the URL cannot be tampered or forged. The client has limited capabilities and I cannot use a key which is more than 50 characters long.

Generally I use RSA to generate the signature, with keys of the proper size. So I am not sure what technique to use to keep the signature safe enough. The key shared with the client will have a validation of 1 year.

Any suggestion?

Improve this question
$\endgroup$
5
  • $\begingroup$ If the client doesn't have to verify the URL (i.e. only the server need to be sure of it) you can use HMAC (instantiated with e.g. SHA-256). If that fits your need, I'll consider turn this into a formal answer. $\endgroup$
    – DannyNiu
    Commented Apr 26, 2023 at 11:17
  • $\begingroup$ Is this 50-character limit for the signature (usually twice as large), the public key (used for verification), or the private key (used for signing)? As an aside, Note: 50 characters among how many? 50 characters is more than enough for an EdDSA public key (256 bit, or 43 characters among 62) or private key (nominally the same size, but it can be safely shortened to half that). $\endgroup$
    – fgrieu ♦
    Commented Apr 26, 2023 at 12:07
  • $\begingroup$ @DannyNiu correct the client doesn't need to verify the URL, it only needs to sign (or even encrypt), so that no one can impersonate the sender. Also a symmetric algo can be used as I can store the client key in the server. $\endgroup$
    – Norcino
    Commented Apr 26, 2023 at 17:03
  • $\begingroup$ @fgrieu the limit applies only to the key used to sign (or encrypt). I will look into EdDSA, as I am not familiar with it. $\endgroup$
    – Norcino
    Commented Apr 26, 2023 at 17:07
  • $\begingroup$ A key used to sign is a private key; it can be EdDSA. A key used to encrypt is either a secret key (which easily fits 22 characters) or a public key (and EdDSA is not for encryption, but there are cryptosystem with comparably compact key that can encrypt). Signature and encryption target almost orthogonal security goals. $\endgroup$
    – fgrieu ♦
    Commented Apr 26, 2023 at 17:42

1 Answer 1

Reset to default
1
$\begingroup$

I decided to change strategy and use encryption instead of hashing. This will allow me to leverage better performance adding also protection over information disclosure, which wasn't originally planned.

I will be using 24 randomly generated bytes and to represent it as string, I will convert it in hexadecimal format and remove the dashes leading to something like this:

// DC9F5FA12000F5439CB091A4D3FF913CC442266C123DE958 -- 194 bits key

AES has a very good security and 194 key length is good enough. I won't accept this answer as I originally asked for signing, and I am still interested in hearing about a solution for that, I might write an answer if i have time to keep researching it.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ I suggest you use some authenticated encryption, like AES-GCM-SIV of RFC 8452: you get encryption and integrity protection, the later differing from signature only by the fact that verification by the receiver requires the key used for encryption. But since that's also the decryption key, that rarely a functional issue. $\endgroup$
    – fgrieu ♦
    Commented Apr 28, 2023 at 6:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.