LoupVaillant / Monocypher

An easy to use, easy to deploy crypto library
https://monocypher.org
Other
593 stars 79 forks source link

Monocypher.org is up. Any comment? #82

Closed LoupVaillant closed 6 years ago

LoupVaillant commented 6 years ago

Here: [http://monocypher.org]()

No HTTPS for now, I'll set that up shortly.

jjzazuet commented 6 years ago

Maaan I wish this was exposed as a React Native library. Cheers!

LoupVaillant commented 6 years ago

Err, I don't know React. What is it, and why would we want to use it?

jjzazuet commented 6 years ago

@LoupVaillant React Native is a Javascript abstraction layer which lets me write (mooore or less) cross platform code for Android and iOS mobile apps.

My comment arises from the lack of access to the Web Crypto API from this special type of environment (read: not nodejs, not a browser), but a runtime I came to know as JavascriptCore.

This limitation leaves us with very little options on implementing, for example, end-to-end encrypted chat capabilities in the way the Signal Framework's double ratcheting protocol works. This is discussed in more detail here. I quote that issue because the Signal folks chose Web Crypto to implement their Javascript library.

So at the moment, it seems that the only viable solution for implementing any kind of cryptographic functionality on a mobile app through React Native's Javascript layer is provided by a thin wrapper around libsodium, proxied though the respective iOS and Android native backends.

So in the face of a lack of Web Crypto access in React Native, if similar building blocks (key generation, signing capabilities, etc...) could be accessed through Monocypher, that would be awesome.

Thanks for such a cool project!

ghost commented 6 years ago

More HTTPS

Consider a redirect to HTTPS on HTTP as well.


Typography nitpick:

and have zero dependency —not even libc.

No space before an em dash. If you want to put spaces around dashes, use an en dash (–) and put spaces around it. So either: "dependency—not even libc" or "dependency – not even libc".


You may want to link to sloccount, I'm somewhat torn if providing a link to https://www.dwheeler.com/sloccount/ may be a greater convenience or not for people who aren't familiar with it.


Test Suite

You may want to state that the official test vectors for each algorithm, if such were made available, are also part of the test suite. See also: #81.


curve25519

Should probably be consistently spelled "Curve25519" with an uppercase C, see https://www.ietf.org/mail-archive/web/cfrg/current/msg04996.html.


A bit late to say that now, but are MB, as in megabits, per second a useful metric for the speed benchmarking? Wouldn't you want to measure in MB, as in megabytes, per second?


Here are libsodium's results for comparison. (Note that libsodium uses optimised assembly for many of its primitives).

Style: Remove the first period or remove the parentheses.


Accessibility: Avoid "here" for links. See for example https://webaim.org/techniques/hypertext/#screen_readers

mikejsavage commented 6 years ago

looks good! I only really have nitpicks:

"zero dependency" -> "zero dependencies"

"Just put monocypher.c and monocypher.h in your project" -> "Just add monocypher.c and monocypher.h to your project"

[www.monocypher.org](need an A record for www) :d

Atom feed link is a 404

should bump up the line height. I usually use body { line-height: 1.5; }


I agree with everything CuleX said


@jjzazuet you could run monocypher through emscripten but I suspect that is not an awesome idea

LoupVaillant commented 6 years ago

@CuleX, @mikejsavage, thanks for the tips, I'll apply them all.

@jjzazuet, I suspect making a wrapper around Monocypher would be quite a bit easier than making a wrapper around libsodium.

@mikejsavage, emscripten may be a better idea than you think: since Monocypher has zero dependencies, compiling it should cause no problem. I even suspect performance could be pretty good, thanks to the very simple data flow inherent to constant-time crypto. Even if it's compiled to straight JavaScript with no asm.js or web assembly, the JIT compiler is likely to have an easy time caching the fast path. I say it should be tested, see what happens.

LoupVaillant commented 6 years ago

A bit late to say that now, but are MB, as in megabits, per second a useful metric for the speed benchmarking? Wouldn't you want to measure in MB, as in megabytes, per second?

Oops, that was in megabytes to begin with. I've changed the benchmark to print "megabytes per second" instead of "Mb/s".

LoupVaillant commented 6 years ago

OK, all done. I'll do the www and HTTPS redirection later. Closing this for now, do re-open it if something comes up.

jjzazuet commented 6 years ago

@LoupVaillant thanks for the advice! I'll give emscripten a go.

mikejsavage commented 6 years ago

btw the benchmark section seems to have lost its font-face: monospace

LoupVaillant commented 6 years ago

Err, works for me… I reckon my CSS doesn't specify that for code, maybe your browser has a non-standard default?

ghost commented 6 years ago

https://www.w3.org/TR/html5/rendering.html#non-replaced-elements-phrasing-content

It seems like the code default style is only recommended to be monospace, but doesn't have to be because the spec doesn't mandate any kind of formatting.

mikejsavage commented 6 years ago

now it has a font-face but it should actually be font-family :d

my bad

LoupVaillant commented 6 years ago

But of course, I should have noticed… Done.

ghost commented 6 years ago

So now that https works, thoughts on an HTTP -> HTTPS forward, HSTS and/or an entry in the https://hstspreload.org/ list?

LoupVaillant commented 6 years ago

HTTPS redirection is done. HSTS feels a bit overkill…