Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lowlevel interface to Digest and Bigarray support #5005

Closed
vicuna opened this issue Mar 19, 2010 · 4 comments
Closed

Lowlevel interface to Digest and Bigarray support #5005

vicuna opened this issue Mar 19, 2010 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Mar 19, 2010

Original bug ID: 5005
Reporter: goswin
Status: acknowledged (set by @damiendoligez on 2011-06-01T15:08:48Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.2
Category: otherlibs
Tags: patch
Monitored by: @gasche tgazagna @glondu @Chris00

Bug description

Hi,

the attached patches add a more lowlevel interface to the Digest module allowing the creation of a context and updating the context with any number of strings before finaling it to create the overall digest. It further adds a Bigarray.Array1.Digest module that allows computing the digest of an array or updating a context with an array. The more lowelevel interface allows creating a digest from e.g. a rope, which internally is a sequenze of strings.

As a special bonus the digesting of a bigarray is done with caml_enter/leave_blocking_section() and can run concurrently with other threads to take advantage of multiple cores. It might be wise to add a size check and only go into a blocking section if the array is larger than for example Page_size.

Unfortunately the same can't be done for strings as the GC can move them while being digested in a blocking section. So digesting strings can not take advantage of multiple cores.

MfG
Goswin

Additional information

The patch is split into 2 parts. The changes to md5.c/md5.h must be applied first and the compiler must be bootstraped to get the new functions listed as primitives. Only then, in a second pass, can the remaining patch be build.

File attachments

@vicuna
Copy link
Author

vicuna commented May 4, 2014

Comment author: @whitequark

I have to mention that "The digests are of cryptographic quality: it is very hard, given a digest, to forge a string having that digest." is no longer true. It is trivial to forge an md5 digest, e.g. see http://fixunix.com/linux/494226-md5-collisions-made-easy.html.

I want to point out that improving the Digest module would invite new usage of it, whereas the right thing to do is to use SHA256 or newer hash functions from cryptokit or a similar external package.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 18, 2020
@xavierleroy
Copy link
Contributor

I'll update the documentation of the Digest module. I agree with @whitequark that it is best to leave the Digest module as it is today and turn to external libraries that provide cryptographically-strong hash functions. For example, nocrypto works over Cstruct.t, which are essentially bigarrays of bytes. This could be a good match for the use case proposed in this issue.

@xavierleroy
Copy link
Contributor

The actively-maintained version of nocrypto is part of Mirage: https://mirage.github.io/mirage-crypto/doc/mirage-crypto/Mirage_crypto/index.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants