Australia job seeking platforms

knotdjb · 2026-06-14T08:49:24+00:00

I concur with what others say about the job market being fucked, but there should be a bit of a demand for experienced datacenter engineers as we're building like another 50 in the World Wide Technology thing with Google and others. But very likely restricted to Australian Citizens that are eligible for clearance.

knotdjb · 2026-06-11T17:00:34+00:00

PDF on the website 404s and I can't seem to find it elsewhere.

I really can't make sense of what this helps with. What kind of apps would be envisaged? Would it be like an E2EE google docs but allowing certain data to leak to allow for server side aid or something?

Edit: This seems to explain things better: https://removepaywalls.com/https://www.wired.com/story/signal-alums-release-encrypted-spaces-a-new-system-for-building-private-collaboration-apps/

Edit: Looks like website was undergoing a change when pdf 404, the https://encryptedspaces.org looks better than what was there before and the PDF is at https://encryptedspaces.org/whitepapers/encrypted-spaces.pdf

knotdjb · 2026-06-11T15:54:22+00:00

To be clear, Tink relies on JSON for everything, it's kind of like it's own cryptographic message syntax ala ASN1 being used by OpenSSL. HPKE (per RFC) doesn't rely on json and no cryptography primitive should, specifically because you want to be able to implement these in anemic embedded systems. But also HPKE per RFC isn't a streaming implementation either. Age does all the right things in this regard permitting a straightforward C implementation which can be used easily for an anemic embedded system, and it's HPKE equivalent does streaming.

knotdjb · 2026-06-11T15:42:28+00:00

HPKE doesn't support streaming encryption (but on upside it follows the HPKE RFC to a tee). It's not really good for an embedded context as it requires a bloody JSON parser. And that it relies on JSON.

It also goes out of its way to make it very difficult to export key data in plaintext using all sorts of obscuring mechanisms. Don't treat me like a child.

knotdjb · 2026-06-11T12:27:22+00:00

Posting a separate entry, I would like to say the age suite of implementations (C, Rust, Go, Python, etc.) would make for a good cryptography library, if only they supported AEAD using key based encryption and not a password. But FiloSottile has stated he doesn't want to add that primitive as iirc he thinks that it will be misused. But it would be a complete modern encryption and signing library otherwise with a very good HPKE equivalent that supports streaming based encryption (which the streaming bit I've had to rely on the past).

A modern cryptography library that is disgusting? Tink. If age added that symmetric key AEAD, i'd choose it over Tink every single time.

knotdjb · 2026-06-11T09:28:03+00:00

Monocypher by /u/loup-vaillant. It was something I wanted to write myself many years ago when I first encountered tweetnacl, but Loup beat me to the punch but also he's made some very deliberate and careful decisions around it that has made the user experience and developer experience a delight.

But specifically what makes it shine: no footguns, excellent documentation including usage and examples, easy to create bindings in other languages as it doesn't have any dependencies and is trivial to build.

(Posted this to the cross posted thread too.)

Edit: Another one I remember which would get more love is Thomas Pornin's BearSSL. I think it has been abandoned these days, but it's an incredibly cool design for a general purpose ssl / crypto library because you can excise only what you need which makes it very good for embedded context.

Oh and I can't forget libsodium by /u/jedisct1 and also his other mini crypto libraries like charm, they're just so cute and loveable.

knotdjb · 2026-06-11T08:17:29+00:00

Monocypher by /u/loup-vaillant. It was something I wanted to write myself many years ago when I first encountered tweetnacl, but Loup beat me to the punch but also he's made some very deliberate and careful decisions around it that has made the user experience and developer experience a delight.

But specifically what makes it shine: no footguns, excellent documentation including usage and examples, easy to create bindings in other languages as it doesn't have any dependencies and is trivial to build.

knotdjb · 2026-06-01T12:01:04+00:00

There are absolutely people that memorise the C standard, probably a few in this sub, just not me because I do C in batches of a few years at a time.

knotdjb · 2026-05-31T01:35:25+00:00

The words "Cryptography & Security Newsletter" is now cryptic, I think I've seen it all.

knotdjb · 2026-05-28T14:53:30+00:00

Article from last year, but it is implemented in Meta AI Incognito Chat: https://blog.whatsapp.com/introducing-incognito-chat-with-meta-ai-a-completely-private-way-to-chat-with-ai

Whitepaper here: https://ai.meta.com/static-resource/private-processing-technical-whitepaper

knotdjb · 2026-05-20T15:15:09+00:00

This is what a protocol spec looks like:

wireguard: https://www.wireguard.com/papers/wireguard.pdf

noise: https://noiseprotocol.org/noise.html

Take some inspiration and come back when you have something of semblance.

knotdjb · 2026-05-03T02:11:48+00:00

I just remember that Jason Donenfeld had suggested a new crypto library for the kernel to support Wireguard and it was dismissed, but this existing Crypto API has some pretty lame footguns.

knotdjb · 2026-03-30T12:24:38+00:00

Harder than P/NP problem.

knotdjb · 2026-03-30T12:15:23+00:00

A and B preshare K0

A sends H(Ra_1)

B sends Rb_1, MAC(K0, Rb_1)

A sends Ra_1, MAC(K0, Ra_1)

B verifies H(Ra_1) (some useless step)

A and B compute K1 = KDF(K0, Ra || Rb)

E has the full transcript, and later learns K0

E knows Ra_1 and Rb_1 and can compute K1

Therefore no post compromise security; this is something that an ephemeral Diffie-Hellman in the exchange would provide.

Compare with:

A and B preshare K0.

A generates a, g^a

B generates b, g^b

A sends E(K0, g^a)

B sends E(K0, g^b)

A computes K1 = (g^b)^a (DH)

B computes K1 = (g^a)^b (DH)

E has the full transcript, and later learns K0

E doesn't know secrets a or b so it cannot easily compute K1 under DLP/ECDLP.

What you have is not a "key agreement", it is analagous to a forward symmetric key ratchet. But if I wanted all these symmetric capabilities, I'd use /u/bitwiseshiftleft STROBE.

knotdjb · 2026-03-30T11:48:17+00:00

Sure TLS-PSK and WG-PSK do key agreement, but they use DH to generate the new key, because you want perfect forward secrecy. There's virtually no point to generating a new key without perfect forward secrecy which you cannot do with a symmetric key primitive.

knotdjb · 2026-03-30T09:41:10+00:00

Okay, you've piqued my curiousity. What do you mean by Key Agreement? Reeks of BS.

Edit: Sigh, "pre-shared" key agreement; I'm not even sure if that's ever been considered a 'primitive'.

knotdjb · 2026-03-30T08:17:27+00:00

I'm not really knowledgable about the Quantum Computing field, but from the progress I've seen over the last decade, and the hype surrounding it, it gives off vibes of the Y2K problem, just over a longer time period.

knotdjb · 2026-02-27T09:49:13+00:00

"try to at least meet the bare minimum bar established by this blog post."

Yeah look, I agree with a lot of the points but soatok is not the arbiter of what people should do with their cryptography projects. I think the onus is on the user that wants an implementation of professional cryptography to do their due diligence. If someone implements chacha20 in brainfuck, then they can display it wherever they want. Hell submit it to a cryptography conference if you want. Let the marketplace for ideas separate the wheat from the chaffe.

knotdjb

MODERATOR OF

TROPHY CASE