digest function based on webcrypto API

[keroxp]

• Implemented digest function based on webcrypto API
• I don't know whether this is the best solution for providing digest or cryptographic features in deno
  • There are another way like exposing pure hashing function on "deno" namespace.
• Based on the discussions, I think cryptographic features should be provided by deno core, anyway.
• I understand that more discussions are needed about this problem, because I don't know whether all features that required by webcrypto API can be implemented by Rust
• I believe that crypto api is important for many other core features, TLS, Hashing.
• I'm Rust beginner, thanks!
  

[CLAassistant]

All committers have signed the CLA.

[hayd]

The ideal thing to do is to build in webcrypto (as mentioned in 48), but I think this is a good stop-gap that will give a forwards-compatible api.

This would already be useful, e.g. for denoland/std#84 (websockets).

[ry]

@keroxp I'm very sorry for delaying this review so long. I have a few problems with this:

The main problem is that data is passed inside of the FlatBuffer message. When data is sent this way, a memcpy is performed. We provide a zero-copy means of sending data to Rust, using the last parameter here:

deno/js/dispatch.ts

Lines 53 to 58 in 7f88b5f

	export function sendSync(
	builder: flatbuffers.Builder,
	innerType: msg.Any,
	inner: flatbuffers.Offset,
	data?: ArrayBufferView
	): null | msg.Base {

At minimum this patch should use the zero-copy method.

The other problem is that digest functions are often used in a streamable way... The way I would organize this is to add a new "resource" type (which is like a file descriptor -- see the last slides here). But this is getting quite complex. I wonder if using WASM for this wouldn't be a better means organizing this?

Finally there's the topic of Chromium's webcrypto. Maybe we can link to this library to provide this functionality. Although this sounds good - I think it's quite difficult and I'm not sure if it's worth it. In particular, //components/webcrypto depends on //base which we don't currently use and overlaps heavily with Rust's standard library in addition to C++'s std library (both of which we already are using). In the future I would like to link Chromium's WebGL implementation into Deno , but it does not depend on //base so it is not clear that linking in //base is something we need to do.

[keroxp]

@ry SHA1 function is now part of deon_std. So may we not need native digest functions immediately? I probably can make a patch around your first pointing, but don't fully understand what you say at the second. If it is quite hard to merge, I'm ok to drop this PR. How do you think?

[hayd]

@ry if we update to the Pinned[Buf] does that alleviate the zero copy concern?
(The streaming issue is a slightly larger problem, I'm not sure how to resolve it... can rust access ReadableStreams? what streamable type are you thinking of here?)

[keroxp]

This PR can't be merged into latest master. drop it.

[hayd]

I think this will be a good approach to add in the future (preferable to algos in ts) using new ops.

[nchavez324]

2 questions from a prospective implementer:

• Does the streamable resource type exist, or does that still have to be created? If not, where's the best place to start reading and hacking?
• By:

if using WASM for this wouldn't be a better means

do you mean implementing the crypto algos in Rust outside of Deno and then invoking them in userland?