lib25519

[jleightcap]

lib25519 is a microlibrary for the X25519 encryption system and the Ed25519 signature system, both of which use the Curve25519 elliptic curve. Curve25519 is the fastest curve in TLS 1.3, and the only curve in Wireguard, Signal, and many other applications (see Nicolai Brown's page https://ianix.com/pub/curve25519-deployment.html).

nixpkgs PRs:

• librandombytes https://github.com/NixOS/nixpkgs/pull/317781
• libcpucycles https://github.com/NixOS/nixpkgs/pull/319608
• lib25519 https://github.com/NixOS/nixpkgs/pull/319618

[jleightcap]

2024-06-06 update:

done

• refactor the configurePhase
• tested build on x86_64-linux, aarch64-linux
• fixed ./configure arguments towards cross-compiling: turns out it's just a Python script, and needed custom configurePlatforms

todo

• pull in the most recent dated version release from upstream librandombytes
• licensing of the Nix derivation we copied from: https://github.com/X-Wing-KEM-Team/xwing/blob/51be12c1d2172592a639d419deaf5ce09c6a1734/shell.nix#L42
• investigating the cross-compiler setup within librandombytes -- will require some manual overridding: we started testing this with env.gcc: but there's potential to do this cleaner (believe env is a anti-pattern.)
  • potential to upstream a more idiomatic naming scheme for compilers: not just gcc but prefixed name e.g. aarch64-linux-unknown-gnu-gcc
• populating the meta field for librandombytes
• ideally all of this configuration translates 1:1 into lib25519 and libcpucycles

[jleightcap]

2024-06-10 update see: https://github.com/jleightcap/nixpkgs/tree/fern/librandombytes

done

• went through @kiike's research into cross-compiling: managed to fix gcc x64>arm cross-compiling
• using clangStdenv: figured out how to override the stdenv when building, clang:x86>x86 work
• started debugging clang:x86>arm : learned about proper dependency placement, nativeBuildInputs versus buildInputs

todo

• stripping doesn't seem to work: build output claims to be running strip, but file $BINARY shows unstripped: file showing not stripped does not mean it has debug symbols. https://stackoverflow.com/a/3284123
• is the clang -Q... CFLAGS actually necessary? it appears in the script to find a compiler, but we're not sure if it needs to actually be applied
• are nix's CFLAGS being applied? (confirm things like best practice security flags are being applied)
• test arm>arm builds, with gcc and clang
• we starting to make changes to the upstream configure script: figure out how to upstream and email the maintainers
• passthru.updateScript (sic): since this is distributed as a tarball
• the rest of the nixpkgs formalities: meta.license etc.

[imadnyc]

done

• confirmed that stripping is happening: file output was misleading, gdb was correct: strip was being called on both binaries and the library .so
• CFLAGS
  • comparing across gcc and clang builds, noting clang has an additional -Q... argument
  • confirmed that nixpkgs CFLAGS are being applied (-O2, -fPIC, -fstack-protector, etc.)
  • -fwrapv: this is flag that librandombytes explicitly sets, why is it not visible in the nixpkgs flags? this is a special case: -fnostrict-overflowis set, meaning:

    -fstrict-overflow
       This option implies -fno-wrapv -fno-wrapv-pointer and when negated implies -fwrapv -fwrapv-pointer. 

todo

• why is -O2 being used when librandombytes requires -O1?
  • if we set env.NIX_CFLAGS_COMPILE = "-O1": this does add that flag, but in addition to -O2. And because -O2 is a super-set of -O1 flags, these used in combination are effectively just -O2. we need a way of disabling, or otherwise overwriting, the default optimization level that Nix uses.

[jleightcap]

for posterity: we moved tracking our day-to-day packaging progress into a group kanban board for the time being. all related packages for this issue have nixpkgs PRs in review.

[jleightcap]

thanks for the reviews @wegank!