-1

I am trying to design an algorithm for publicly sharing authenticated messages.

Obviously, asymmetric public/private key schemes do this, but I want to avoid the requirement that users have to keep track of a lengthy asymmetric key. Instead, I only want users to keep track of a password that can be hashed to make the keys that they need. All other information is shared publicly.

I hope to achieve this using an elaborate scheme involving HMACs where the HMAC keys are released after the message has been successfully signed and published. An attacker can't fake a message, because he would only be able to sign and publish a message after the corresponding HMAC key has been released.

The real author needs to prove that the HMAC key they used is the correct HMAC key. To do this they must publish a hash (or HMAC) of the HMAC key beforehand, so when they share the HMAC key it can be authenticated as well.

So it basically will work like this:

  • Alice wants to publicly share authenticated messages using only a secret password.
  • She generates an initial HMAC key using her password.
  • She publishes the hash of that HMAC key so that it can be later verified.
  • Later, when she wants to publish a message she does the following:

    • Uses her password and a counter to generate a replacement HMAC key and a hash of that replacement HMAC key.
    • uses the previous HMAC key to sign the message she wants to publish.
    • uses the previous HMAC key to sign the hash of the replacement HMAC key.
    • shares the signed message and the signed hash of the replacement HMAC key.
    • Once both have been published, she shares the previous HMAC key itself.
    • Everyone else uses the previously published HMAC key hash to verify the HMAC key is correct.
    • They then use that HMAC key to authenticate the message and replacement HMAC key.

I would appreciate some feedback on the security implications of my invented scheme if you have time to thoroughly understand the described algorithm.

This is my best attempts to create a scheme for publicly authenticating messages using only a password. What I would really like to know is if there is a viable way to do this.

I have become convinced that the best alternative is to have users who don't want to keep track of a lengthy private key use a trusted third party service that stores an encrypted version of that key. When they want to sign a message, they download their encrypted key from that service, decrypt it, and then sign their message the normal way. If I could do better I'd like to know.

  • ben.mord.io/p/delayed-chained-key-revelation-dckr.html I seem to have rediscovered and extended your idea. In DCKR, a chain of keys are derived via iterative hashing of initial secret random seed so that a single "public key" can survive extended usage. A hierarchy can similarly be constructed to improve certain delegation features (kinda sorta like a backwards BIP-32, if you're familiar with Bitcoin). (CAUTION: as I've not yet found precedent (let me know if you have!), we might have to assume this is a very low-mileage idea with little or no useful peer review as of yet.) – Benjamin Mord Nov 16 '17 at 20:07
1

Your invented scheme releases "a hash (or HMAC) of the HMAC key",
relies on trusted timestamping, and allows an attacker to exchange
"the message she wants to publish" with "the hash of the replacement HMAC key".



The following is a viable way to do what you're trying:

  • Alice wants to publicly share authenticated messages using only a secret password.
  • She generates a signature key-pair using her password.
  • She publishes the hash of the verification key.

    • Uses her password to regenerate the key-pair.
    • uses the private key to sign the message she wants to publish.
    • shares the signed message and the verification key.
    • Everyone else uses the previously published hash to verify the verification key is correct.
    • They then use that signature verification key to authenticate the message.



Your "best alternative" could be improved by having the trusted third party store an authentication
token too. "When they want to sign a message, they download their" salt "from that service,"
derive regenerate the authentication token and key, send the authentication token, "download
their encrypted key from that service, decrypt it, and then sign their message the normal way."
(The point is, that stops everyone other than the third party from mounting an offline password search.)

  • I made some changes to my question based on your feedback. Your response answers my updated question as well. I didnt think about the possibility of generating a key pair from the password. Makes sense. Thanks – derekmc Sep 22 '14 at 18:29
  • Now if only I could quickly implement the algorithm you described. – derekmc Oct 2 '14 at 14:10
  • just found this: github.com/wwwtyro/cryptico – derekmc Oct 2 '14 at 14:13
  • also look at this question: stackoverflow.com/questions/11156275/… – derekmc Oct 2 '14 at 14:16
  • @derekmc Notice that this answer allows for short private and public keys, and it is essentially impossible to do make them any shorter without compromising the security. The drawback of the presented approach is that the signatures themselves will be fairly long. If you don't have any constraints on the signature length, then I believe this answer is optimal. – kasperd Feb 19 '15 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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