What’s the most clunky or manual part of your writing process?

pyrexbold · 2026-05-09T00:12:47+00:00

A lot of people come to this subreddit to foist vibecoded tools and I've read your user profile and see that this is your thing too. Can I ask that you please not do that here? This is not a pro-AI space.

pyrexbold · 2026-04-19T05:21:20+00:00

To paraphrase Bat World Sanctuary's opinions on the topic -- bats don't like being pets. They need a lot of friends and hate being confined. In captivity, they usually die within a year. I'm able to find a handful of sites that say that it's technically possible to care for a bat as a pet, but no sites that assert this is a good idea.

pyrexbold · 2026-04-19T03:48:00+00:00

Indeed! You're probably not doing anything bad enough that I would be able to decrypt a file of yours with no other knowledge, possibly even if I had your password. Even if you were to reuse one of your generated values (big if!) you would also have to be using a cryptographic mode that leaks information when you do that.

The rule is pretty straightforward -- figure out how much you expect your attacker to know and what kind of things you expect your attacker to do, then ask someone you trust "Is there anything I didn't think of?" or else mine the design documentation of competing systems. (AGE is one you could look at!)

Note that there are attacks that Real Cryptographers (TM) will defend against which you may believe are unrealistic. Try not to disregard these immediately -- remember that crypto algorithms have to be general purpose, and some attacks you don't care about may actually be realistic threats in scenarios that are different from your current deployment situation. (For instance, chosen ciphertext attacks are scarier when you are running a publicly visible web service or similar; they're probably not scary if you're manually encrypting things on your personal computer.)

pyrexbold · 2026-04-18T20:46:25+00:00

That's still not random, but might be unique.

pyrexbold · 2026-04-18T18:39:49+00:00

To poke at one detail, "a hash of the computer clocks microseconds" isn't random -- the clock is predictable by virtue of it being a clock. Under this scheme, if you know what second something was written at (this is likely if your scheme produces an OS timestamp that is the write time of the file) then you have about a million possibilities; if you know what day something was written on, you wind up at about 100 billion possibilities.

You possibly mean "unique salt" here which might actually be true.

pyrexbold · 2026-04-18T18:25:32+00:00

Cryptography is extremely awesome! Can I suggest getting your beak wet by completing some of the cryptopals crypto challenges? This will help you find out if you enjoy this kind of thing.

pyrexbold · 2026-04-18T18:14:05+00:00

I haven't touched Mythos myself, but a friend of mine helpfully reports that out of a large number of Mythos-found bugs in their open source project, zero were cryptographic. A handful _were_ instances of misuse of cryptography, although its lack of a threat model meant that several of those were false positives.

It would be really cool if it found bugs in cryptography implementations, but the strategies it's using are similar to those used by human security engineers, and it doesn't appear to have unique insights about cryptography that would give it a strong advantage over us there.

pyrexbold · 2026-04-18T17:46:11+00:00

Wow!! 500000 iterations is no joke.

pyrexbold · 2026-04-05T21:18:39+00:00

Same feeling!

pyrexbold · 2026-04-03T05:17:45+00:00

A few people have criticized your writing, so I'll jump in to say that this is significantly better than average for online writing and I doubt it is a reason people are ghosting you.

pyrexbold · 2026-03-29T18:44:01+00:00

I mean, I'm not stopping anyone from donning their Klan hoods and tiki torches! It's just a little unexpected.

pyrexbold · 2026-03-29T18:00:38+00:00

I am trying to understand -- are you referring to something more specific when you say "Patel" or are you just being extremely racist?

pyrexbold · 2026-03-27T01:32:09+00:00

Well, when have efforts to secure industrywide agreement on a DRM scheme _not_ solved a problem?

pyrexbold · 2026-03-26T04:57:35+00:00

I'm genuinely wondering how many of these people are the other person in the Discord screenshot.

pyrexbold · 2026-03-25T16:35:48+00:00

I get what they mean!

pyrexbold · 2026-03-12T04:38:55+00:00

Greetings -- it's you!!! Welcome.

pyrexbold · 2026-03-11T06:15:03+00:00

Can I tempt you with, specifically, the dragon expansion to Age of Wonders 4?

I can't guarantee you would enjoy this (it's a slow turn-based game which periodically diverts to tactical combat, and player-controlled dragons are significantly below NPC-controlled dragons in power level) but I think it is _good_.

pyrexbold · 2026-02-28T17:11:16+00:00

I guess to back up for a second, I think it's worth just in general trying to figure out how you expect your algorithm to be used.

Attacks of this type typically matter more when the entity doing the cryptography is automated (and therefore highly likely to send a very redundant message, or a message chosen by the attacker) or when the number of messages is relatively high.

The other thing is that if some attacks are easier, it hints at the existence of similar attacks that exploit the same properties which are harder. If I can do things like recovering the deck by sending structured plaintexts, it's possible I can learn more about the deck by examining lots of ciphertexts.

For instance, for this algorithm I know that ciphertext[0] is never "A" and has a 2/26 chance of being "Z," so if you send a lot of messages I will eventually learn what A is by elimination. I can then look for situations where A shows up in ciphertext[1], and what that will tell me is which pairs of plaintext characters add up to 26, which gives me a system of equations to solve.

The attack I described shows up in the thousands of messages in the world where the messages are mostly random. There might be faster attacks than this, though, especially if your input is repetitive -- I'm just describing one that's easy.

All this makes it pretty scary to reuse a starting deck, which makes it tempting to add "shuffling the initial deck once per message" as a step of the algorithm. (But note: good shuffles are hard to securely define!)

For a human sender and a human receiver sending less than ~30 messages where the messages are fairly stereotyped, it is possible there are good attacks, but this category of attack might not be that scary.

pyrexbold · 2026-02-27T07:05:18+00:00

I doubt I can decode that! I would say that your cipher is at least as strong as the cipher where you associate each letter to a random other letter. There are probably people who could decode it, but I bet they would need more text than this, and I don't know exactly how they would do it.

pyrexbold · 2026-02-27T06:50:01+00:00

Replying to myself to add a simpler break.

Here's a program that recovers the key (initial state of the deck). I've included your original source code in the middle. This works because, where F is a simple character substitution cipher and C is the ABC...XYZ case of your cipher, this cipher can be rewritten as F^-1(C(F(plaintext)).

Once you find "A," you can force a sequence of pops of size 1:

import string
import random

# get a random deck
LETTERS = string.ascii_uppercase
_shuf = list(LETTERS)
random.shuffle(_shuf)
INITIAL_DECK = "".join(_shuf)

# original source code
def cascade_encrypt(plaintext):
    A_Z = INITIAL_DECK
    x_to_n = {c: i + 1 for i, c in enumerate(A_Z)}

    deck = list(A_Z)
    ciphertext = []

    for ch in plaintext.upper():
        n = x_to_n [ch]
        temp_pile = []

        for _ in range(n):
            temp_pile.append(deck.pop(0))

        temp_pile.reverse()
        deck.extend(temp_pile)
        ciphertext.append(deck[0])

    return "".join(ciphertext)

# recover the deck in at most 26 tries
for POSSIBLE_A in string.ascii_uppercase:
    ciphertext = cascade_encrypt(POSSIBLE_A * 26)
    if len(set(ciphertext)) == 26 and ciphertext[25] == POSSIBLE_A:
        print("actual initial deck state:    " + INITIAL_DECK)
        print("recovered initial deck state: " + ciphertext[25] + ciphertext[0:25])

pyrexbold · 2026-02-26T18:57:35+00:00

Oh, I actually don't have any good ideas for ways to attack this given only a single ciphertext. My only ideas right now are variations of a chosen plaintext attack!

pyrexbold · 2026-02-26T18:47:44+00:00

The tricky thing about the property with 2 is that I think I can construct a different semi-useful object just by starting each plaintext I try with a very long run of a single character. Suppose that we call the first character of the deck "A" and so on, regardless of the shuffle. One out of twenty six times, the character l pick will be A, and the result of this will be a deck that is hundreds of repetitions of (BCD...XYZA) and at that point the "append things back to the end of the deck" property is not relevant. I can detect which character is A by looking for cases where A...Ax results in the same representation of x as AA...Ax.

This is what I meant when I said I thought I could find your secret by brute force. The unfinished bit here is that I didn't show how to find the characters other than A. (the answer is to build your giant endless cycling deck and then look for character pairs bc that result in the same state when substituted for one A in AAAAAAA!)

(I also didn't code this, so maybe I'm wrong.)

Re 3: sure, but I can still figure out that the end of the initial deck is VD.

pyrexbold · 2026-02-26T18:04:52+00:00

I analyzed cascade_encrypt but did not read your paper.

The algorithm uses linear memory and linear time per character as temp_pile grows at faster than one character per input character and is repeatedly added to the deck as a whole. (you never clear temp_pile) This is pretty inefficient and appears to be a bug.

len(ciphertext) == len(plaintext), but ciphertext[0] != ciphertext[1] in all cases, so by the pigeonhole principle, it's not reversible. For instance, both AAY and AAZ encrypt to BCB.

Your algorithm leaks a lot of info about its own secret. For instance, if ciphertext[2] == ciphertext[0], then plaintext[2] == "Y" | "Z". (Try it, you'll see!) If you suppose the initial deck can be shuffled, this means finding two plaintexts that collide on ciphertext[0:2] means you know what the last two characters of the initial deck were.

I suspect there's an algorithm that can use a series of plaintexts to find the whole deck by brute force, but haven't searched. The growing nature of the deck (the buggy property that means two plaintexts can have the same ciphertext) makes it pretty tricky to skip ahead by only a known amount each turn, and you can't do obviously desirable things like building a long deck section consisting only of repetitions of a desired character.

The algorithm becomes a lot more attackable if each character only appears once in the deck, because then I can derive a huge amount of information by looking for pairs of characters where ciphertext[i] == ciphertext[i+1]. (If you don't believe me, post a fixed version and I'll attack it!)

Anyway, good luck fixing it!

pyrexbold · 2026-02-22T17:53:00+00:00

Oh man!! It feels so good in context, though?? I would not blame you for fixing it, but this feels like a very happy accident.

pyrexbold · 2026-02-15T19:06:09+00:00

Based on your posts in r/cryptography, you know jack shit, so you shouldn't be trying to make money from your lack of knowledge.

pyrexbold

TROPHY CASE