Hash upgradability
From Erights
(Difference between revisions)
Kevin Reid (Talk | contribs) (Proposal #2) |
|||
(3 intermediate revisions not shown) | |||
Line 11: | Line 11: | ||
* 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. | * 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) | **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) | **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]] | [[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.