# Digital signatures using a partially public key

I'm thinking to sign a message using a key that is made up of a publicly shared key and a privately shared key. The operation for mixing the two keys could be concatenation, if it suffices.

To formalise it a bit, the signature is essentially $$MD5(msg, concat(pub, priv))$$

Since the entire key isn't (completely) known to the public, are such signatures considered secure? Should the merged key be hashed and/or derived from a KDF before applying it to MD5 (or HMAC for that matter)?

Perhaps, something like $MD5(msg, concat(KDF(pub, n), priv))$ where $n$, the number of rounds, is randomly derived from the public key? The rationale is that even if the attacker knows the public key, they won't be able to derive n, which protects the private key from some kind of text attack.

• What would the intended use of such a signature? What could someone do if they only knew the public key? Could they (for example) verify a signature? – poncho Sep 25 '15 at 4:06
• The signature is for verifying that the message is authentic. The same private key will be hard coded in all devices, so the threat model is that someone holding onto a device knowing someone else's public key could fool the master about the authenticity of the messages. Verifying the signature isn't so harmful here; I'm hoping to defeat the threat of spoofing signatures. – Kar Sep 25 '15 at 4:13
• Obvious problem of this that a real public-key signature scheme does not have: whoever can verify the "signature", can forge it. – fgrieu Sep 25 '15 at 6:37
• Sure. But isn't it the case for all symmetric key digital signatures? Compute the hash of the message and match against the signature. – Kar Sep 25 '15 at 6:38
• You are talking about message authentication codes (MAC) not signatures. I guess you can take any secure MAC and use as key e.g. the XOR of a public and a private value. However, you will only get the security guarantees of a MAC not of a signature. – mephisto Sep 25 '15 at 6:50

## 1 Answer

A few things. First of all, MD5 is broken, and no longer suitable for cryptographic purposes. Instead, prefer newer algorithms, like those from the SHA-2 family (SHA-256, SHA-512, etc).

Second, the term "signature" in cryptography is defined more narrowly than you would expect. It specifically refers to situations where there is a public key (the "verification" key), and a private key (the "signing" key). Everyone can verify a signature themselves, if they have the public key.

It sounds like what you're actually after is a Message Authentication Code (MAC). MACs use a single "secret key" for both signing and verifying, instead of having separate keys for each purpose.

Since that's the behaviour you want (assuming I understood your comments correctly), it's best to use an algorithm designed for that purpose, such as HMAC-SHA256.

• I see. In 2006, RFC 4635 calls for 96 bit truncation. I believe the recommendation is to increase by 16 bits a decade. So how about SHA-1 truncated to 112 bits? – Kar Sep 26 '15 at 11:37
• Sure. HMAC-SHA1 truncated to 112 bits has less of a security margin, but should be fine. – Tim McLean Sep 26 '15 at 21:02