libpepcli is for testing/learning purposes. For secure operation, please use the (C++/Rust) API directly.
Aangaande 6: beter om een ScalarNonZero te hebben (zoals de Rust versie), zodat die per definitie geen 0 is. Aangaande 10: hergebruik van code was dat, zodat in dat andere project ze allemaal dezelfde random gebruiken. Is hier denk ik niet nodig idd.
Fixed this crash on Windows. Different STL library, so different handling of iterators in string_view in debug mode (in the FromHex function).
Bernard van Gastel (5d5e57c7) at 05 Jul 09:01
Fix crash on Windows
Oh no, line breaks... Always 'fun'. I suspect that is in the PubHubs code? Because the CLI should output '\r\n' on Windows... (that is expected behaviour).
Thanks! We tried the quick hack, which did work (fortunately we did have a setting for selecting the libpepcli binary so could just switch that to peppy). But in the end we cannot yet get the hub and the central PH server to communicate mutually agreeable pseudonyms, I suspect line endings somewhere in a script :p . That will take a bit longer to look into.
Thanks for the report. I will take a look into this, if I can reproduce it locally. For now, you can use the Rust version of the library, Harm knows the details how to install it. I suggested to Harm that PubHubs can move to the Rust version of the library, eliminating the need for a different executable, simplifying the set up even more.
If you want a quick hack:
cargo install libpep
Bernard van Gastel (65b1f346) at 26 Nov 11:45
Updated brew links.
Bernard van Gastel (d3c22918) at 26 Nov 11:45
Changed Brew name.
Bernard van Gastel (aa45ee78) at 26 Nov 11:39
Updated brew links.
Bernard van Gastel (483dc10a) at 24 Nov 19:32
Throw exception if inverting 0 (which is like division by zero).
Bernard van Gastel (afb3a2ab) at 19 Oct 16:09
Added copyright notices.
Dank je. Veel van deze elementen komen uit een grotere bibliotheek. Dat is o.a. de reden voor 2 (CMake gebruikt C++ 17, maar er wordt bij dat andere project een compiler flag voor -std=c++2a toegevoegd), en 10 (grotere project gebruikt dezelfde random bron voor meerdere onderdelen). Ik heb dat nu al meteen aangepast voor dit project.
Nu aangepast: 1, 2, 4, 5, 7, 11 (functie was left over van experiment, weggehaald).
De rest ga ik nog naar kijken en aanpassen (behalve 3, want dat werkt in gcc).
Super fijn!
Het ziet er goed uit. Ik heb wel wat vragen/opmerkingen:
Ik heb const char*
moeten veranderen in auto
in base.cpp
regel 233 om te kunnen compileren met MSVC
Waarom andere C++ standaard voor Android? Betekent dat niet dat je dan sowieso alleen maar C++17 features kunt gebruiken? Of, als je #ifdef gebruikt, dat je in ieder geval een C++17 implementatie moet leveren. Kun je dan niet net zo goed alleen C++17 gebruiken?
Het compileert voor mij sowieso niet met C++17:
src\core.cpp(16): error C2039: 'invalid_argument': is not a member of 'std'
include\base.h(117): error C2668: 'radboud::pep::_SHA512Update': ambiguous call to overloaded function
Die eerste is makkelijk op te lossen door #include <stdexcept>
toe te voegen.
In lib-common.h
: werkt clang diagnostic push
ook in gcc? Dit wordt gebruikt in een blok #if defined(__clang__) || defined(__GNUC__)
Ik zou de voorkeur geven aan Scalar::is_zero
, ipv Scalar::zero
. Duidelijker dat het een boolean is, en niet je scalar op 0 zet oid.
Scalar::valid
vind ik minder ambigu, maar zou ik dan ook is_valid
van maken. Idem voor GroupElement
.
Ik vind Scalar::base
een onduidelijke naam voor wat het doet. (kan aan mij liggen, misschien is het gebruikelijke terminologie)
mult_base
oid zou ik duidelijker vinden
Scalar::invert
controleert niet of de input 0 is, of de return value van crypto_core_ristretto255_scalar_invert
die -1 returnt als de input 0 is. Moet dat niet gecontroleerd worden?
Goed dat de error in Scalar::base
een hint geeft over wat er mis kan zijn. Op basis van de libsodium-documentatie zou ik zelfs zeggen dat je 'probably' weg kunt laten.
In GroupElement::operator+
en GroupElement::operator-
wordt de return-value van de gebruikte libsodium-functie niet gecheckt.
Libsodium zegt bij beide functies:
The function returns 0 on success, or -1 if p and/or q are not valid encoded elements.
Ga je er vanuit dat ze nooit invalid kunnen zijn (door de check in FromHex
)? Dit zou je expliciet kunnen maken met EXPECT
.
Scalar::operator==
en GroupElement::operator==
zijn niet constant-time. Alle gebruikte libsodium-functies zijn dat dacht ik wel. Is dat iets wat we hier ook willen?
In RandomBytes
gebruik je een functie die niet in de libsodium documentatie genoemd wordt. Hij lijkt er vooral vanwege NaCl-compatibiliteit in te zitten. Waarom gebruik je niet randombytes_buf
?
RerandomizeY
voert een voor mij onbekende actie uit. De functie wordt ook nergens gebruikt, en staat ook niet in core.h
.
Dus wat is hier precies de bedoeling van?
Bernard van Gastel (24b700c6) at 20 Sep 11:52
Changed namespace from pep to libpep.
... and 1 more commit