Hash upgradability

From Erights

(Difference between revisions)
Jump to: navigation, search
 
Line 5: Line 5:
—[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
—[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
-
=={{Proposals}}==
+
==Proposals==
* Simple: rename cryptoHash to sha1Hash. Add other algorithms as desired. --[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
* Simple: rename cryptoHash to sha1Hash. Add other algorithms as desired. --[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
:Disadvantage of this: Does not allow code to be sensibly generic over hash algorithms without taking an arbitrary verb to call on Integer. --[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
:Disadvantage of this: Does not allow code to be sensibly generic over hash algorithms without taking an arbitrary verb to call on Integer. --[[User:Kevin Reid|Kevin Reid]] 17:30, 29 August 2009 (CDT)
-
[[Category:[[Unesolved design issues]]
+
* Define explicit hash algorithm objects, and provide a standard one which is SHA-1. Also add a provision to ask for the current recommended hash algorithm.
 +
**Simple: Hash function which takes and returns integers, just extracting the current cryptoHash/0 facility. --[[User:Kevin Reid|Kevin Reid]] 18:09, 29 August 2009 (CDT)
 +
**Complex: Also take the opportunity to handle (1) hash large data blocks or streams without turning them into integers first and (2) permit returning an array of octets rather than a big integer as the result, when this is more directly useful. See [[HashAlgorithm]] for a proposed protocol. --[[User:Kevin Reid|Kevin Reid]] 18:09, 29 August 2009 (CDT)
 +
::I support that proposal as it promotes decaupling --[[User:Zarutian|Zarutian]] 11:49, 10 April 2010 (CDT)
 +
 
 +
==Notes==
 +
 
 +
Designation of hash algorithms by programs, if part of the solution to this issue, should use some sort of well-defined namespace. See [http://groups.google.com/group/friam/browse_frm/thread/76b2a1dc8e72ae4b/e2014c634b1db4c7?#e2014c634b1db4c7 this friam list thread: Apr 2, 2010] for discussion. David Hopwood's [http://www.users.zetnet.co.uk/hopwood/crypto/scan/ Standard Cryptographic Algorithm Naming] is the right sort of thing, but not being maintained.
 +
 
 +
[[Category:Unresolved design issues]]

Latest revision as of 16:49, 10 April 2010

E integers have the operation cryptoHash/0 which performs a SHA-1 hash on the two's complement representation of the number. This will be an unfortunate permanent choice once SHA-1 is broken.

We should switch to an interface which acknowledges the need for hash algorithm upgrade.

Kevin Reid 17:30, 29 August 2009 (CDT)

Proposals

  • Simple: rename cryptoHash to sha1Hash. Add other algorithms as desired. --Kevin Reid 17:30, 29 August 2009 (CDT)
Disadvantage of this: Does not allow code to be sensibly generic over hash algorithms without taking an arbitrary verb to call on Integer. --Kevin Reid 17:30, 29 August 2009 (CDT)
  • Define explicit hash algorithm objects, and provide a standard one which is SHA-1. Also add a provision to ask for the current recommended hash algorithm.
    • Simple: Hash function which takes and returns integers, just extracting the current cryptoHash/0 facility. --Kevin Reid 18:09, 29 August 2009 (CDT)
    • Complex: Also take the opportunity to handle (1) hash large data blocks or streams without turning them into integers first and (2) permit returning an array of octets rather than a big integer as the result, when this is more directly useful. See HashAlgorithm for a proposed protocol. --Kevin Reid 18:09, 29 August 2009 (CDT)
I support that proposal as it promotes decaupling --Zarutian 11:49, 10 April 2010 (CDT)

Notes

Designation of hash algorithms by programs, if part of the solution to this issue, should use some sort of well-defined namespace. See this friam list thread: Apr 2, 2010 for discussion. David Hopwood's Standard Cryptographic Algorithm Naming is the right sort of thing, but not being maintained.

Personal tools
more tools