1
$\begingroup$

I am searching for a simple hash algorithm(s) which can be used to calculate relatively secure hash without using of any computer. Some requirements:

  • use only simple arithmetics operations (+ - / *, maybe mod and abs)

  • base of 10 (letters can be substituted with groups of 2 digits), not binary

  • short time of calculations (limited number of operations per hash and limited number of digits per number)

  • simple calculation (normal person should be capable of memorize it)

  • if whole calculation could be done in memory, it would be a plus but it is not necessary

  • only short messages will be hashed (maximum 50 - 100 characters, about 35 on average)

  • relatively secure (of course no modern computers will be used to reverse / find a conflict)

Edit:

there is similiar question here: Is there a simple hash function that one can compute without a computer?, but all responses seems to be too complicated to fit in my requirements

$\endgroup$
  • $\begingroup$ What security properties are thought: Collision resistance, preimage resistance, or something else? Alternatively, what's the intended use? It's MUCH easier to make a passable MAC than a hash. $\endgroup$ – fgrieu May 11 at 16:00
  • $\begingroup$ Purpose is to allow an individual without mathematical background to easily generate list of hashes which can be passed to another person, who can do the same to verify if they have the same informations (= list of keys) $\endgroup$ – ts01 May 11 at 16:05
  • $\begingroup$ @AleksanderRas from all responses maybe Fletcher’s checksum $\endgroup$ – ts01 May 11 at 16:08
  • $\begingroup$ Is it assumed that the alteration of the information to check is accidental, or could it be adversarial? In the former case, you want a checksum, have you checked the Luhn algorithm, and mod 97 of IBAN? In the later later case, what can it be assumed that the adversary knows/can do? What is the initial format of the information hashed? Will the hash(es) be public, and in that case is the information/key hashed wide/random enough that it wont be a security issue? $\endgroup$ – fgrieu May 11 at 16:19
  • $\begingroup$ "Too complicated answers" is not really a good reason to re-ask a question. It would lead to answers spit over two questions - if it can be answered at all as it is currently stated. Explain what you don't understand about a specific answer and maybe ask if that can be clarified. $\endgroup$ – Maarten Bodewes May 17 at 17:17
0
$\begingroup$

There has been a similar question. The accepted answer there refers to Manuel Blum's HCMU hash function.

Check out Manuel Blum's human computable hash function. He calls it HCMU for Human Computable Machine Unbreakable.

He claims you have to spend an hour memorizing the technique and then you can apply the has function in about 20 seconds without even using pencil and paper.

I have found an implemention of this function here, in just over 60 lines of Python code. Unfortunately I cannot find any paper on it on the go and the link in that other question is broken.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Wouldn't just fixing a certain key of your choice make it into a hash? I'm honestly not sure, but that's my understanding. $\endgroup$ – Hubert Jasieniecki May 11 at 14:44
  • 1
    $\begingroup$ Well, fixing a certain key turns a MAC into a function with the same input domain and possibly the same output domain as a hash, but not necessarily the right security properties (like collision-resistance, preimage resistance). We have a real-world illustration with HMAC-MD5: that's an unbroken MAC, but with fixed public key it becomes a hash with badly broken collision resistance. $\endgroup$ – fgrieu May 11 at 15:55
  • $\begingroup$ [repost with updated link, and more analysis]: My understanding of the HCMU scheme, based on this and this, is that's it's not a hash, it's a MAC. The huge difference is that it requires a secret password/key (a random permutation of the digits 0-9). The security argument seems to revolve on that secrecy, and the assumption that the <22-bit key will be enough... $\endgroup$ – fgrieu May 11 at 16:06
  • $\begingroup$ Presence of secret key doesn’t fit my requirements (but overall method seems to be quite close of ideal) $\endgroup$ – ts01 May 11 at 16:10

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