His password was intercepted, or was embarrassingly deterministic.
Though from this description it looks like they read the disk (trivial) but it's not sure if they actually pulled anything from it (at least it seems they didn't pull anything incriminating if I read it correctly).
If they were using a crib sheet to the point of only trying 1m attempts, this can be done in “days” with one CPU even if PBKDF2 is set to take one second each attempt on that CPU.
A “better” KDF isn’t fundamentally going to change this. It’s just going to enforce stricter limits on any time-memory trade offs and require more memory. Neither of these are going to be meaningful differences when you’re cracking a single password for a single user with a crib sheet, unless you’re in the realm of billions or more guesses.
MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
The original sentence already came with this disclaimer.
> and we should be transitioning to even more secure passphrases. [newline] Or does it? Let's go into what LUKS is doing in the first place.
That sentence really should have been put into the introductory paragraph, instead of being the start of the 2nd.
There is no such thing.
b) The first two sentences of the next paragraph read:
> Or does it? Let's go into what LUKS is doing in the first place
Someone who doesn't know in detail the math of how this stuff works but _does_ know how to run tight opsec could very reasonably assume that now fairly long passwords can be brute-forced. That's like, the entire point of the article, innit? Describing how this almost certainly _wasn't_ an attack on the password, but almost certainly an attack on the mechanisms that use that password as an input to crypto.
+1
To be clear, the person I was replying to was all like "You _idiot_. Obviously the plaintext of the guy's password was in the possession of the attacker!", when the primary (if not the entire) _point_ of the article was to set up and answer the question "Well, what if it _wasn't_? Is it possible using default settings to brute-force a password?".
Password/passphrase cracking is done with sophisticated (and in cases like this one, likely tailored to the target) strategies that try more likely possibilities first. In such a scenario, "supposedly greater than 20 characters and [including] a mixture of cases, numbers, and punctuation" tells us little about how difficult it was to crack.
For example,
A11 y0ur b4s3 4r3 b3l0ng 70 u5!
(not many know this, but gpt secretly is french for Government Person Trained!
The eventual goal, is that the gubberment will have mental maps of us all, and even use that to test meme class mental manipulation techniques on this simulated populous, to best determine those sweet words to control us.
Rebels will become loyalists, anarchists state advocates, our very natures used to control us!)
https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
If you're the attacker and your goal is to do 1000 (≃ 2^10) rounds of SHA1 for each of those 2^119 potential passwords, couldn't you then just try to brute-force the 128-bit key directly, since 119 + 10 >= 128?
Put differently, wouldn't the statement "A fully random 20-character password has been cracked" amount to saying "AES-128 has been broken"?
For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U ( Q3'18) CPU, that appears to result in an iteration count on the order of 1-2M. Assuming those hashcat benchmark numbers scale linearly on the iteration count, you're down to about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256.
Assuming 10kH/s, that drops you down to roughly 45 bits of entropy for 1k gpu-months, or 250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits).
OTOH it's easy to generate a 20-character password with far less entropy.
[1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
They then use that strings output as input into the password cracking rig. They are happy to let it churn for months / years (because the case is working through the system).
So its far more likely this individual hibernated his PC with the password in memory or reused the password elsewhere than it was cracked.
Is that the case? I would be surprised. I would assume success ratio does not change much by checking say 10^4 more combinations (it's either a simple combination of these strings and common prefxies/suffixes or if it's complex then the amount of combinations grows so fast that you are unlikely to get a hit)
I'm betting on the second option, he reused the same password somewhere else or they just got lucky ans seized the computer already unlocked
Don't think this is the case?
Prove me wrong. Show me in their source code of the OS you're running that they don't do this.
The absence of auditability is evidence for tyranny. Auditability in the case of software is open source software and open source hardware, up and down the entire stack of the device in use. Anything short of that, and you're pwned without even being able to know or prove it -- when it comes to government.
While it is technologically possible, I have never heard of a case of this actually happening.
https://en.wikipedia.org/wiki/Entropy_(information_theory)#c...
> English text, treated as a string of characters, has fairly low entropy, i.e., is fairly predictable. We can be fairly certain that, for example, 'e' will be far more common than 'z', that the combination 'qu' will be much more common than any other combination with a 'q' in it, and that the combination 'th' will be more common than 'z', 'q', or 'qu'. After the first few letters one can often guess the rest of the word. English text has between 0.6 and 1.3 bits of entropy per character of the message.[6]: 234
Consider the difference in entropy between this totally randomly generated password, consisting of 4 words each from a pool of 100,000:
Correct Horse Battery Staple 4lg(100000) = 33
And this one of the same length where each character was chosen from a bank of 68:
VIW&jubiHZUgBrFA8PI9Vy1E(%G 28*lg(68) = 170
That being said I don't understand your calculation of 4lg(100000). That seems like it can't possibly be correct. For starters it is entirely independent of the entropy content of the words in the dictionary. I could have 100000 strong random passwords of 1000 characters each in my dictionary. Could you explain this a bit, please because there's obviously something I'm missing?
I think you mean 66. More realistically, 52 for Diceware's 7776-word dictionaries, or 44 for XKCD's 2000 common words.
https://towardsdatascience.com/perplexity-of-language-models...
(I have not checked this claim, it's just what I found from googling "best large-language model character-perplexity 2023".)
A token in a LLM is generally more than one character, so I would guess that the entropy is a bit lower than that. Shannon estimated it at 0.6-1.3 bits/character in 1950 (https://mattmahoney.net/dc/entropy1.html)
I think the discrepancy here is coming from the fact that you are assuming the password is using English words, where others are assuming completely randomly selected characters from the set /[a-zA-Z0-9]/, plus some special characters, which yields substantially more than 1 bit per character.
"the SDAT explains that they began to tail me and the other comrade (quickly exonerated) starting last January"
[1] https://anarchistnews.org/content/update-letter-ivan-alocco
Careful, that math assumes each character was chosen randomly, which isn't how people usually pick passwords. If the password contains words and patterns, then it was much weaker. "Passwordpasswordpass" matches those requirements, and is decidedly weak.
But I agree, password reuse or other similar mistake seems likely.
2^114/350e18/3600/24/365 = 1.9e6
Even 2^114 itself is only 2 * 10^34
> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy.
Upper/lowercase are already 52 characters. If we add digits (0-9) we are already looking at log_2(62^20) = 119 bits of entropy.
On that note: Let's assume the password were indeed purely random and had 119 genuine bits of entropy. If you're the attacker and your goal is to do 1000 (≃ 2^10) rounds of SHA1 for each of those 2^119 potential passwords, couldn't you then just try to brute-force the 128-bit key directly, since 119 + 10 >= 128?
Put differently, wouldn't the statement "A fully random 20-character alphanumeric password has been brute-forced" amount to saying "AES-128 can be brute-forced"?
Your calculation is correct. My point still stands (2 million years is plenty of time), but my number given was completely off. I can't edit it anymore though.
This calculation is for exhausting the entire search space, right? Not guessing at random (which would invoke the birthday paradox?). For block solving on Bitcoin, clients don't search the whole space. They try random values and check if it's right.
I'd assume the random guesses for bitcoin miners is because with a deterministic chunk of the search space you risk the possibility that someone else chose the same chunk and so already tried all the values you're trying
Sorry but there's no world in which this password was bruteforced in 2023, even if they were using just SHA1 as their PBKDF. Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. To put this in perspective, if you could use the entire global bitcoin mining equipment (estimated at 350 million terahashes / second) right now without modification to bruteforce this one password it would still take you 4 x 10^37 centuries. The author of the article failed to do this basic math.
The dude reused passwords, got keylogged, powned some other way, was coerced, had something unencrypted, or something else happened. But his password did not get bruteforced.