Add SHA1 support to crypto_data_hash/3

[danilp-id]

As discussed in #2316, one can use Scryer to verify Github's 2FA.

The default hash algorithm used in TOTP is SHA1, which is also used by Github: https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#manually-configuring-a-totp-app

Relevan't RFCs:

• HOTP: https://datatracker.ietf.org/doc/html/rfc4226
• TOTP: https://datatracker.ietf.org/doc/html/rfc6238

[triska]

crypto_data_hash/3, and library(crypto) in general, so far only implements algorithms that are considered secure.

Since SHA-1 is insecure and deprecated, I would advise against adding it to library(crypto).

Ideal would be a Prolog-based reference implementation, also for ongoing standardization efforts of this predicate.

[danilp-id]

@triska should argument of hmac/1 predicate be a string instead of a list of numbers representing bytes?

[triska]

No, it should be a list of bytes. The convention in library(crypto) is that things that are meant to be random (like cryptographic keys) are lists of bytes. Things that "mean" something (like plain text, ciphertext and hashes of data) are represented as chars.

One of the motivations for this is: In UTF-8, bytes above 127 are represented differently than bytes 0..127, which only take a single byte. And therefore using lists of chars for cryptographic keys may leak data about keys when measuring the time of operations in which these keys are involved.

The risk of this actually happening may be very low. But still, I prefer to represent cryptographic keys as lists of bytes, because bytes are represented uniformly and should take the same time to process.

[triska]

Good news: Byakuren has added ISO Prolog based reference implementations of several hash algorithms and their documentation to Flowlog! Please consider contacting her in case you have any comments or additional requests, the Flowlog page explains how!