• Re: Stop with Openpgp

    From kdog@noreply@gmail.com to alt.privacy.anon-server,alt.privacy,alt.cypherpunks on Wednesday, September 02, 2026 23:01:20
    From Newsgroup: alt.privacy

    Don Jhon wrote:
    kdog wrote:
    Openpgp as standard brings with it a surface that I have to expose to unauthenticated input:
    packet stream parsing, S2K, compressed packets, subkey bindings to validate, and above all RSA PKCS#1 v1.5, which is very bad when the failure becomes observable, by timing, by log, by a bounce. A modern envelope must be a single AEAD open: it fails or not, indistinguishably. The OpenPGP path has dozens of points where it can fail differently, and each is a potential cesspool. This is why I keep it isolated in its own module, with size cap before parsing, no compression, mandatory SEIPD and uniform failure. Not because RSA is broken, but because the format forces me this way.


    The other half of the problem is that legacy Zax-style nymservs cannot have forward secrecy nor the hSub ratchet: the key is static, by definition. So a seizure while the machine is running retroactively ties them to all their past posts.


    YAMN did the right thing in 2013 and still does: NaCl Box hop-by-hop, AES-256-CTR, Blake2, deterministic header padding against tagging attacks, binomial pooling. It's an honest, living Type II. But it's forward-only, no reply block, no SURB, and that's not a detail: it's what determines the entire architecture of nymserv, and the reason why the code you sent me couldn't work. Maximum chain 10 hops, body 17920 bytes, fixed format.

    It's not Sphinx and doesn't have the properties of Katzenpost.
    It's my watermark and i assume it.

    Kdog

    --- Synchronet 3.21e-Win32 NewsLink 1.2
  • From Gab virebent@gabriel1@virebent.invalid to alt.privacy.anon-server,alt.privacy,alt.cypherpunks on Thursday, September 03, 2026 01:22:07
    From Newsgroup: alt.privacy

    kdog wrote:
    Don Jhon wrote:
    kdog wrote:
    Openpgp as standard brings with it a surface that I have to expose to unauthenticated input:
    packet stream parsing, S2K, compressed packets, subkey bindings to validate, and above all RSA PKCS#1 v1.5, which is very bad when the failure becomes observable, by timing, by log, by a bounce. A modern envelope must be a single AEAD open: it fails or not, indistinguishably. The OpenPGP path has dozens of points where it can fail differently, and each is a potential cesspool. This is why I keep it isolated in its own module, with size cap before parsing, no compression, mandatory SEIPD and uniform failure. Not because RSA is broken, but because the format forces me this way.


    The other half of the problem is that legacy Zax-style nymservs cannot have forward secrecy nor the hSub ratchet: the key is static, by definition. So a seizure while the machine is running retroactively ties them to all their past posts.


    YAMN did the right thing in 2013 and still does: NaCl Box hop-by-hop, AES-256-CTR, Blake2, deterministic header padding against tagging attacks, binomial pooling. It's an honest, living Type II. But it's forward-only, no reply block, no SURB, and that's not a detail: it's what determines the entire architecture of nymserv, and the reason why the code you sent me couldn't work. Maximum chain 10 hops, body 17920 bytes, fixed format.

    It's not Sphinx and doesn't have the properties of Katzenpost.
    It's my watermark and i assume it.


    What I really get rid of it's GnuPG.

    However, you need a YAMN client with updated stats and a NNTP source
    over Tor to catch messages from a.a.m., and we have it !

    :)

    Gabx
    --
    https://contact.virebent.art
    --- Synchronet 3.21e-Win32 NewsLink 1.2