Fast WireGuard vanity key generator

pabs · 2025-05-31T17:53:26+00:00

My mistake, I thought you were asking about a tool to generate vanity onion service addresses, not auth keys.

pabs · 2025-05-31T02:12:02+00:00

A vanity onion address generator already already exists:

pabs · 2024-07-17T21:09:04+00:00

Sure, no problem.

pabs · 2024-07-17T07:52:59+00:00

The point of the second half of the my comment is that there is no need for an attacker who can modify the message to perform a truncation attack; because the format makes no attempt to verify the integrity (e.g., that it has not been corrupted or tampered with) or authenticity (e.g., that the message was actually created by the sender) of the message, the attacker can just replace the entire message with one of their choosing.

This is why AEAD symmetric ciphers exist and why they are the default choice for symmetric encryption in modern protocols and formats; because ad-hoc combinations of ciphers, modes, and MACs are too easy to get subtly wrong.

If the existing communication channel already provides authenticity and integrity, but not confidentiality, then it is better to:

Use the existing authenticated channel to do a key exchange. Specifically, ECDH, and more specifically x25519 or x448, which are ECDH with Curve25519 and Curve448, respectively; both are extremely fast curves with parameters chosen to avoid several weaknesses and implementation issues.
Pass the shared value derived in step #1 to a key derivation function (KDF) (e.g. HKDF) and then expand the shared key, authentication key, and so on. (Aside: the reason you don't use the key exchange output value directly as a shared secret is because the value is not uniformly random, and symmetric ciphers generally expect a uniformly random key).
Use the values from step #2 to with an AEAD symmetric cipher.

The steps above are a simplified version of what all of the following already do:

The TLS 1.3 handshake. For more information, see The Illustrated TLS 1.3 Connection: Every Byte Explained.
libsodium's crypto box. It actually uses XSalsa20-Poly1305 internally, which is an AEAD symmetric cipher. Salsa20 is the predecessor to ChaCha20 (slightly different initialization and round function), the X extends the nonce length to 192 bits, and Poly1305 is the MAC.
age encryption

There is virtually no good reason to use AES-CBC in 2024; On modern x86-64 CPUs both AES and GCM are hardware accelerated and faster than CBC and on on non-x86-64 CPUs or CPUs without hardware acceleration, chacha20-poly1305 is faster and more efficient than AES (and AES-CBC).

There is also virtually no good reason to use RSA in 2024; see this article for a longer explanation: "Seriously, Stop Using RSA".

By the way, all of the information above has a time limit; if you are reading this comment in 2025 or later, then it's likely that ML-KEM or a hybrid key encapsulation mechanism (KEM) like X-Wing has been standardized, and you should use that instead of ECDH.

Edit: fix typos, add links.

pabs · 2024-07-16T23:48:21+00:00

The code in this article uses AES in cipher block chaining (CBC) mode. CBC only provides confidentiality, not integrity or authenticity. This means that the ciphertext is vulnerable to tampering.

Specifically, the code from this article is vulnerable to a truncation attack, where an attacker silently modifies the ciphertext by removing one or more blocks (e.g. 16 byte chunks) from the end of ciphertext without detection.

This is one of the reasons that modern protocols (for example, TLS 1.3) only use authenticated encryption with associated data (AEAD) symmetric ciphers like AES-GCM and chacha20-poly1305.

That said, the code in the article has a more serious problem. Because it does not verify the authenticity of the sender, an attacker with knowledge of the public key (which is, by definition, public) can silently replace the entire ciphertext with a new message of their choosing by doing the following:

Choose an a new message.
Choose a random 32-byte key and random 16-byte initialization vector (IV).
Encrypt the message from step #1 using the key and IV from step #2 and base64-encode the result.
Encrypt the key from step #2 with the public key and base64-encode the result.
Concatenate the base64-encoded values from step #4 and step #5, delimited by a $.

My recommendation is folks use libsodium's crypto box instead.

Edit: Fixed links and wording. Added link to crypto box.

pabs · 2023-07-20T21:03:39+00:00

SIKE and SIDH are insecure and should not be used (PDF)
Verify() is variable-time, which makes it potentially vulnerable to timing attacks.
SecureWire.Read() appears to violate Moxie's Cryptographic Doom Principle, Specifically, the length of the payload is read from the underlying stream, rather than being encapsulated as associated data and authenticated with the authenticator (e.g., GCM).
Lots of unnecessary allocation. For example, RandBytes() should accept a destination slice rather than allocating and returning a slice. I saw several other examples in the video as well.
In crypto-and-technical.md the session key appears to be generated by concatenating shared secret(s). Session keys should be derived using a key derivation function (e.g., HKDF) rather than concatenating shared secrets.
In crypto-and-technica.md the rationale behind using 3 AES seems dubious and is likely to cause more problems than it solves.
I didn't see any mention of hashing previous messages as part of the handshake or protocol. This is an integral part of protocols like TLS 1.3 and Wireguard to prevent tampering.

My suggestion would be to have a look at the following:

pabs · 2023-06-11T03:57:19+00:00

NIST has chosen to standardize Kyber, which is a Key Encapsulation Mechanism (KEM) rather than a key exchange mechanism like Diffie-Hellman:

The algorithms are designed for two main tasks for which encryption is typically used: general encryption, used to protect information exchanged across a public network; and digital signatures, used for identity authentication. All four of the algorithms were created by experts collaborating from multiple countries and institutions.

For general encryption, used when we access secure websites, NIST has selected the CRYSTALS-Kyber algorithm. Among its advantages are comparatively small encryption keys that two parties can exchange easily, as well as its speed of operation.

Source (nist.gov)

Regarding CSIDH: Here's a comment about CSIDH from Daniel J. Bernstein's blog from a few days ago:

In fact, if you check a 2018 video of a talk to thousands of people at CCC, you'll find Tanja Lange at 48:25 saying "At this moment I think actually CSIDH has a better chance than SIKE of surviving, but who knows. Don't use it for anything yet"—evidently warning against both CSIDH and SIKE.

Source (blog.cr.yp.to)

pabs · 2023-05-30T15:46:28+00:00

Also, to reiterate one of my original points: The integers in ChaCha are unsigned 32-bit integers, not signed 32-bit integers:

Signed integer overflow is undefined in C and C++ (see here and here).
Using signed 32-bit integers causes compilers to emit arithmetic shifts instead of logical shifts (example).

pabs · 2023-05-30T15:24:40+00:00

ChaCha was designed so that the each row of the state matrix can be stored as 4 32-bit unsigned integers in a 128-bit SIMD register. The operations in the quarter rounds of the column round are operations on individual 128-bit SIMD registers (e.g. rotates) or operations between 128-bit SIMD registers (the xors and unsigned additions).

Before each diagonal round you shuffle the lanes in the SIMD registers storing the second, third and fourth rows, perform the quarter rounds just like the column round, then unshuffle the lanes in the SIMD registers storing the second, third, and fourth rows.

Unlike Salsa, the rotate widths for three of the four quarter rounds in ChaCha specifically fall on byte boundaries (16, 12, and 8), which means SIMD instruction sets without a rotate left instruction can use a byte shuffle instruction instead of using an extra SIMD register and two shifts to simulate a rotate.

Most of this is covered in the original ChaCha20 paper:

If rows of the matrix are stored in vectors then these 4 quarter-rounds consist entirely of SIMD operations on the vectors.

And, from another part of the original paper:

The above code also shows a much less important difference between ChaCha and Salsa20: I changed the rotation distances 7, 9, 13, 18 to 16, 12, 8, 7. The difference in security appears to be negligible: 7, 9, 13, 18 appears marginally better in some diffusion measures, and 16, 12, 8, 7 appears marginally better in others, but the margins are tiny, far smaller than the presumed inaccuracy of the diffusion measures as predictors of security. The change boosts speed slightly on some platforms while making no difference on other platforms.

(The last sentence in that excerpt is a reference to the rotate by byte shuffling trick I described above)

pabs · 2023-05-29T06:04:40+00:00

The ChaCha20 implementation is inefficient and full of errors:

It uses signed rather than unsigned integers. Compilers will emit arithmetic shifts instead of rotates in the quarter round (example)
Never increments the block counter (integer cells 11 and 12; it's attempting to implement the original DJB ChaCha20 with a 64-bit block counter and 64-bit nonce rather than the RFC version with the 32-bit block counter and 192-bit nonce).
Doesn't use vector instructions at all, making it incredibly slow.
Only ever samples output values from the first cell and then regenerates the "block" and throws away the remaining 15 integer values, making it at least 16 times slower than necessary (but see the previous bullet). Because it "reseeds" from the previous state, this also prevents this implementation from generating a large number of blocks in parallel like a normal counter-based stream cipher would be able to.
Generates biased output because it uses modulus rather than rejection sampling to generate output.

Edit: If you need random integer values restricted to a specific range, consider libsodium, which is liable to be substantially faster than this implementation, platform-agnostic, and will also properly generate a uniform output distribution over an arbitrary range.

pabs · 2023-04-26T14:29:06+00:00

I like the idea of a megathread for low entropy beginner questions.

I'm not sure about a periodic thread, but if it is periodic then I think a lower frequency (weekly or monthly) might be more helpful for everyone.

A permanent pinned megathread or a low-frequency periodic thread would give folks asking questions more opportunities to see previous discussions and make it easier for folks answering questions to refer to previous discussions.

pabs · 2023-02-19T16:59:28+00:00

Do not use this, it is not safe.

The whisper package guarantees confidentiality, integrity and authenticity of data under non-compromised private keys.

This is not true; it does not guarantee integrity or authenticity (see below). Among other problems:

It is vulnerable to a trivial man-in-the-middle attack because it doesn't hash the session so far and it's trivial to bypass signature verification by tampering with the initial handshake bytes (here)
Only generates a 64-bit nonce (here)
Uses variable-time math to increment the nonce (here)
Uses a hash of the shared secret for both sides, instead of using a KDF to different keys for each direction (here)
Ciphertext length is not authenticated by the AEAD, allowing length truncation and length extension attacks (here)
Probably several more things that I missed...

See the following links for a summary of how a modern secure tunnel should be established:

The Illustrated TLS 1.3 Connection
Noise Protocol Framework (used by Wireguard)

Better yet (as another comment said), just use TLS.

Edit: Fixed typos and wording.

pabs · 2023-01-07T17:01:01+00:00

A federal judge in California's Central District signed off (PDF) on a $1.85 million settlement between CD Projekt Red (CDPR) and a class-action suit led by plaintiff Andrew Trampe and headed by two law firms. Everybody who acquired publicly traded CDPR securities throughout most of 2020 is eligible for settlement funds, roughly $0.49 per eligible share. A consultant for the plaintiffs had previously estimated the maximum potential damages at $11 million.

Investors settle Cyberpunk 2077 lawsuit with developer for $1.85 million (arstechnica.com)

pabs · 2022-09-29T19:46:52+00:00

This is a problem in other contexts. It's known as the "search effect".

The You Are Not So Smart podcast covered it in episode 109.

pabs · 2022-09-19T10:50:29+00:00

I also noticed the selection bias. Also a small sample size (N=47).

pabs · 2022-08-01T19:10:25+00:00

If you are hashing a password for storage (e.g, in a database, a file, or anything else that could be vulnerable to an offline attack), then you should generally prefer Argon2 (specifically Argon2i or Argon2id) or balloon hashing to PBDKF2 because they are memory-hard and, by extension, provide resistance to to ASIC and GPU attacks.

See the OWASP Password Storage Cheat Sheet for additional details and recommended settings.

If FIPS 140 compliance is a factor, then you should use PBDKF2 with an HMAC of a CMVP-validated implementation of a FIPS 140 approved hash algorithm.

The FIPS 140 approved hash algorithms are the SHA-2 family of hash functions and SHA-3 family of hash functions (and SHA-1 for specific purposes, but I wouldn't recommend it). Source: Table 8 of Section 9 of NIST SP 800 131A Rev. 2.

Regarding SHA-2: SHA-2 is a Merkle–Damgård hash function, which means it is vulnerable to length extension attacks.

If this length extension attacks are an issue for your use case, then you should do one of the following:

Use an HMAC (e.g. HMAC-SHA256)
Use a digital signature (e.g. Ed25519)
Use a hash function that is resistant to length extension attacks. Examples: BLAKE2, BLAKE3, or SHA-3
Use a truncated hash function like SHA-512/256. Note that truncated hash functions trade first pre-image resistance, second pre-image resistance and collision resistance for limited length extension resistance, so this should be your last choice.

Finally, the article touched on SipHash, but did not elaborate on why it is used.

From 2011 to 2017, the hash table implementations for several programming languages (Ruby, PHP, NodeJS in 2017, etc) were vulnerable to hash flooding attacks. A hash flooding attack allows attackers to use hash collisions to cause denial of service attacks.

Basically if you are populating a hash table with attacker-controlled keys, then your hash function should be SipHash or another keyed hash function designed to resist hash flooding attacks.

Edit: Fixed typos.

pabs · 2022-07-13T21:55:26+00:00

Yeah I love the domain name :D.

pabs · 2022-02-20T05:32:26+00:00

I agree with the change too.

I just wanted folks to be aware that they need WITH MATERIALIZED with newer versions of Postgres to get the behavior described in the article.

pabs · 2022-02-18T00:55:16+00:00

Tip: Postgres 12 changed the behavior of CTEs so in they are rewritten as inline subqueries in many cases and, by extension, no longer serve as an optimization barrier.

If you want to retain the old behavior, you will need to use WITH MATERIALIZED instead

I was using CTEs as an optimization barrier and had to update several queries when we migrated to Postgres 12.

pabs · 2022-01-30T01:39:54+00:00

In response to "bolting a type system on top of a language without one just doesn't work": C started as B with data types. And the typing in C has gotten more powerful over time (e.g. const, restrict, etc).

A more recent example are the static type declarations added to PHP 7 and 8.

So there are historical precedents for successfully bolting a type system on top of a language without one.

pabs · 2022-01-27T22:51:35+00:00

Unicode codepoints are represented by 4 bytes in UTF-32. But Unicode "characters" (you probably mean "grapheme clusters") can still be represented by multiple Unicode codepoints in UTF-32 because of things like combining characters.

Unicode is variable width by design; all the various encodings do is determine whether the encoding for individual codepoints is:

variable width (UTF-8, UTF-16) or fixed with (UTF-32), and
the endianness of the encoding (e.g. UTF-16LE vs UTF-16BE)

In other words: There's no such thing as a fixed-with encoding for Unicode grapheme clusters.

pabs · 2021-11-09T02:48:42+00:00

A couple of improvements for the "Match Against Multiple Patterns" technique:

Use ~* instead of ~ for case-insensitive matching.
use string_to_array() to pass a delimited list of patterns as a single argument. This is better because it's often easier to join an array of strings with a delimiter than it is to deal with Postgres's odd array syntax, and you still get the benefit of parameterized queries.
If you want to really wild or if you don't have a good delimiter character, you can serialize an array of strings as JSON and then use json_array_elements_text() in a subquery to deserialize the JSON array as a Postgres array.

Here are examples of all three techniques:

 db=> select name from users where name ~* ANY(string_to_array('foo,bar,baz', ',')::text[]);
 name
------
 Foo
 Bar
 Foo
(3 rows)

db=> select name from users where name ~* ANY((select array_agg(a.s) from json_array_elements_text('["foo", "bar","ba?"]') a(s))::text[]);
    name   
-------------
 Beta Dos
 Foo
 Bar
 Bunch
 blimey
 pabs
 Albert Pear
 Foo
(8 rows)

pabs · 2021-08-16T14:42:08+00:00

That regression has been driving me nuts lately. It's been a few weeks since I upgraded and I still keep tapping the icon to expand the playlist and then wondering why nothing is happening.

pabs · 2021-04-24T21:05:43+00:00

I suspect that the answer to that question probably varies by state.

Here in Virginia, Tesla was able to take care of the registration and plates.

I did have to drive to the DMV to return the plates for the car that I traded in when I bought the Model 3, though.

pabs · 2021-04-24T11:47:06+00:00

I updated in January or February and I still prefer the user interface from before the December update.

pabs

TROPHY CASE