emurlin

Joined 5 years ago

Karma
104
Submissions
90
Member since
Mar 5
Available for contract work

CV: https://dl.riv.ar/cv/20231031_CV_Vieitez_Parra.pdf?sha384=JmAhMRM3_6xNQQAPDX3OzYrgmzZ2PlqnA1bVyJqnTNyjC64p-VM5BEJEvsT3_sSN Blog: https://apeleg.com/blog/

View on Hacker News

Recent submissions

Comment · 1 month ago
Good article, thanks for sharing! I agree with the claims it makes _and_ the reasoning behind them.

This was motivated for situations where using GPG just isn't practical. The issue is that there are very limited options to share a file securely without needing to install additional software (ZIP files come close to this, with some important caveats).

As I was making this, I tried to mitigate many of the concerns raised in that article. For example:

> ask for an file that can be decrypted with an ordinary standalone decryption tool

You don't need to run the self-decryption code at all. You can use 'ordinary' tools like `openssl` to decrypt the contents (note to self, add the `openssl` instructions to the `<noscript>` rendering).

> People who publish decryption tools expend effort to ensure that recipients can trust the actual decryption tools themselves before running them.

You _can_ verify the integrity of the tool itself using gpg. Since you can't verify the entire HTML file (otherwise, you wouldn't be able to inject the encrypted payload), there's ways a malicious actor could add additional scripts and still pass the integrity check. However, if you're diligent enough to be using gpg to check this, you'd likely also be diligent enough to spot such additions, or you'd be using the openssl route.

Comment · 1 month ago
Author here. For the main use case that motivated my building this (securely sharing sensitive-ish data with non-technical people), yes, a ZIP file may have been preferable. That is what I was using before making this.

ZIP files can use two types of encryption, ZipCrypto or AES. As the sibling comment points out, ZipCrypto is pretty broken. IIRC the AES encryption is OK or mostly OK, but it's not universally supported, so your recipient may or may not be able to open the file you send them. Notably, the Windows built-in ZIP implementation didn't support ZipCrypto (this may have changed now that Windows ships with bsdtar / libarchive).

Subjectively, I feel this can be simpler to use (mostly for the recipient). You can host it at some server, share the link and the password and the recipient can access it like a regular website and get a plaintext download file. Compare that with a ZIP file, which with the same flow give you a ZIP download: if they don't immediately extract it, then they may have to hunt for the password later.

Comment · 1 month ago
Correct
Comment · 1 month ago
Yeah, I was inspired by self-extracting archives. I wanted to share files with basically no dependencies.

The goal was:

1. Something that didn't require any installation (assuming a web browser)

2. Have a single file with no network that could self-decrypt

3. Be fully auditable

The second point is done by having (sort of(*)) reproducible builds and embedded OpenPGP signatures.

The first point is made by cleverly manipulating the HTML structure so that it can decrypt without breaking the PGP signature. It can even decrypt using bare openssl (which was a design goal too, though getting the exact structure right took some work and bug reports).

The third point is accomplished by the first two, and by the source being freely available.

(*) Depends on the OS at the moment.

Comment · 7 months ago
This is a browser-based JS benchmarking tool I've been working on for the past weeks, unsatisfied with the alternatives that are out there. The goal is / was supporting most features one would need (like NPM or JSR packages), setup and teardown code, seamless support for async code, etc. and at the same time present a report with not just raw speed (as most tools do) but with useful statistics.

The project is split into two parts, one which is this ready-to-use web UI (obviously, useful for testing in the browser), but also a minimal library that can orchestrate the tests and produce a report (with some nice CLI-based reporters too).

Comment · 8 months ago
In this case, it's based on a per-user secret key and AES-256, which with some careful key and IV-derivation, allows you to have a deterministic (and reversible) address for any given domain name. The basic principle (applied to ids, which extends to domain names) is in this blog post: https://apeleg.com/blog/posts/2023/03/30/enumeration-timing-...

If you're willing / able to sacrifice reversibility, a more orthodox approach can be hash (or *MAC) based. For example, SHA-256(secret + domain-name). However, a key point of this project is attribution, to avoid the need of storing a large set of pre-generated addresses, for portability and for easy reverse aliases.

In terms of the actual SMTP bits, I'm currently relying on Cloudflare workers for receiving and delivering (just a nice and gratis API); however, extensibility within reason is a goal (in scope: provider-agnostic API; very probably not in scope: an SMTP client / server).

Comment · 8 months ago
Most of my time goes to Group Income (https://groupincome.org) / Shelter (https://shelterprotocol.net), a protocol and platform for building rich decentralised rich (web) applications with end-to-end-encryption. The idea is building the tech for an experience rivaling or surpassing that of siloed apps but with a focus on user and data autonomy.

The rest of my time goes into a few personal projects, most with no public URL yet.

  * An IndieAuth provider based on WebAuthn, the idea being that instead of relying on delegating authentication, it could be handled directly using, e.g., U2F keys or a device.
  * A temporary e-mail address provider with deterministic addresses for attribution.
  * A self-service menu / ordering service
  * An E2EE document signing solution
Some of these have led to a few mini-projects that I actively maintain due to not finding a fitting solution, such as:

   * An HTTP media type negotiator (https://github.com/ApelegHQ/ts-http-media-type-negotiator) -- negotiate based on accept headers. This was because I couldn't find a negotiator that correctly parsed headers.
   * A JS sandbox (https://github.com/ApelegHQ/lot) -- Tried to implement something lightweight yet functional
   * A MIME multipart encoder and decoder (https://github.com/ApelegHQ/ts-multipart-parser) -- Attempt at a lightweight, general and spec-correct parser
   * A lightweight ASN.1 DER encoder (https://github.com/ApelegHQ/ts-asn1-der), meant to be used with its sister project (https://github.com/ApelegHQ/ts-cms-classes) --- Part of the document signing project
In addition, trying to move a side-side project to Svelte 5:

    * A web-based self-contained encryption/decryption tool (https://github.com/ApelegHQ/ts-cms-ep-sfx) --- Created to easily share files with maximum compatibility (ZIP archive inside a CMS payload) and minimum requirements.
Comment · 9 months ago
https://riv.ar

At the time, it's mostly just a web CV (with some effort put into implementing RDFa and microformats). The intent is adding a blog section too.

Comment · 1 year ago
Comment · 1 year ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton