# sha256 (etc)

The file builtins/sha256.e (not an autoinclude) contains a simple sha256() implementation.
There is a matching hand-crafted/selected pwa/builtins/sha256.js for use with pwa/p2js.
There are also builtins/sha512.e (not p2js compatible and no equivalent), builtins/sha1.e and builtins/hmac.e (the latter two being fine under p2js).

string result = | sha1(string msg) -- returns a secure 20-byte hash of msg.
string result = | sha256(string msg) -- returns a secure 32-byte hash of msg.
string result = | sha512(string msg) -- returns a secure 64-byte hash of msg.
string result = | hmac_sha1(string msg, key) -- returns a 20-byte keyed-hash message authentication code.
string result = | hmac_sha256(string msg, key) -- returns a 32-byte keyed-hash message authentication code.
string result = | hmac_sha512(string msg, key) -- returns a 64-byte keyed-hash message authentication code.
string result = | hmac_digest(string s) -- return s as a hex-string

#### Notes when used under pwa/p2js, as opposed to desktop/Phix:

I am not the best person to ask about any security considerations; one thing I can say is the output seems to match that of other implementations. Another thing I have read and would agree with is that plain text over https is undeniably far more secure than client-side hashing and sending over plain http, but I have no authority to back up even such common sense claims. Likewise it would be total lunacy to publish sensitive keys in client-side JavaScript, however well you might think they are hidden, at least that is in my unqualified opinion. One thing I can say with some confidence is that any private keys must be retrieved from a server in a way that no-one else can replicate however much they study your (open source JavaScript) code, and even better yet make any api calls from server-side code (which probably has access to better sha routines), but again I am not the person to ask precisely how all that might best be achieved. Note that in particular sha256.js is only included because many web/rest api demand the use of SHA-256, then again they might well be advising against invocation of their api from client-side JavaScript.
Note that for sha256() desktop/Phix accepts/requires/returns a (binary) string msg/result, whereas pwa/p2js returns a sequence of bytes and accepts a string/sequence argument, which should only ever matter (in a typeless language) when explicitly tested for, and/or perhaps when displayed.
Every JavaScript implementation (of sha256) I could find yielded a human-readable hex string, and the one I finally settled on was no exception, but I modififed it to yield raw binary. Such strings are/were great for tests, and demos, and passing on to a web/rest api, but are a real hindrance to any kind of double-hashing, which includes all hmac and blockchain uses. At the moment there is no official way to convert the binary into such a human readable string but I could probably dig something up easily enough should it ever be needed. Likewise a suitable sha512.js could probably be fairly easily found/modified, the bigger question is whether or not there is any real point to the time and effort.