>>223425

Perhaps. Perhaps not.

There are two reasons it would have been this. Either it was a trip code intended purely for a short term operation and the time for it to be cracked using a dictionary attack was seen as workable.

Crypto is disposable. There is a reason it is regularly cycled in the operating world. Even randomly generated 128 bit crypto keys are cycled within a fiscal quarter. Exact schedules are obviously classified.

Or - the fact that people would try to, and eventually succeed in cracking Q's trip was used as a clue or data point in and of itself. Consider it clue on a lit fuse.

Although, if I understand correctly, the trip code is a hashed algo using an input. There is no "getting close" to breaking it. The difference in output is radically different from minor changes in the input (or should be). Getting an output string that is "close" doesn't imply "close" to having the input string. Or shouldn't.

>>223483

The "password" in trip codes is a hash algorithm input. The output is displayed.

It is not an account where the password can be changed. It is like program code for a machine that has an unpredictable response to instructions. The way we know 'it is you' is that you are the only one with that specific set of instructions and I can't easily make a set to get the machine to do the same things.

>>223489

The trip code, itself, isn't AES256. The hash out for that is stupidly long. It's a 64 bit output. If I want your trip code, I can crack it in an afternoon with an FPGA card, assuming I have the algo and we are using 8 bits per character. Can't see trips on my current device, but they aren't very long.

The fact it took them this long if they had the algo to run natively is more curious than anything else. If it's an AES based cypher, you can FPGA that and hit three orders of magnitude hash rate over a single CPU, using a modest card. If you have a server FPGA and can code it…