8 ms·

> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of

by orlp 4y ago

> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced. 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.

mjg59 4y ago
The presumption that 20 characters is any meaningful amount of entropy is based on the password actually being somewhat random, and there's no fundamental reason to believe that that's true. I tend towards brute forcing not being the most likely reason for this, but the indisputable reality is that any combination of weak passwords and PBKDF2 makes it plausible (if not necessarily likely) that an adversary with a sufficiently large hardware budget can break disk encryption.
- deleted 4y ago
  [deleted]
- aborsy 4y ago
  You don’t need to merely tend towards. You just can’t brute force a random 20 characters password of the type that he mentioned. Brute force is almost never used, even with half of entropy of such password. His password was intercepted, or was embarrassingly deterministic.
  - raverbashing 4y ago
    Or something like, notebook still had the keys in memory when it was recovered 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).
  - mort96 4y ago
    I didn't see anyone mention a random 20 characters password. I saw 20 character password with symbols and upper and lower case. That might be 4 words strung together "correct horse battery staple" style.
  - mjg59 4y ago
    A stronger KDF would plausibly have protected him even if his password was embarrassingly deterministic.
    - stouset 3y ago
      Maybe. But probably not. 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.
- AlexCoventry 4y ago
  If the computer is suspended at the time it's seized, does it become easier to recover the FDE key from the computer's memory? Or is that encrypted with the user password, or something like that? (On stock ubuntu, say.)
  - mjg59 3y ago
    If you can dump the contents of memory then you have the key (after all, the CPU has to be able to encrypt and decrypt the material, so it has to be available).
    - zamnos 3y ago
      Pedantically, if there's an HSM/similar hardware in play, the CPU only asks for material to be encrypted/decrypted and doesn't have the key in system RAM to be able to do so itself. MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
    - ryan-c 3y ago
      Apparently it's possible to keep the key in the debug registers: https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
  - zamnos 3y ago
    If the DRAM is powered on at the time of seizure, recovering the key is eminently possible. If this is an issue for you, completely power off the laptop when transiting customs. https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
segfaultbuserr 4y ago
> so in the absence of any sort of opsec failures [...] The original sentence already came with this disclaimer.
- wallmountedtv 4y ago
  Agreed. Annoyingly the author does split up a very core idea to the next paragraph: > 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.
  - eduction 4y ago
    Disagree, long paragraphs are more annoying than breaking up thoughts like this. I think it's reasonable to expect a reader to continue to the next paragraph, and corrosive to start writing for poor readers (distracted, skimming, etc - let people who do this bear the risk and consequences of their actions rather than changing writing to make this behavior less risky)
- comboy 4y ago
  > absence of any sort of opsec failures There is no such thing.
simoncion 4y ago
a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec. 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.
- mjg59 4y ago
  I don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
  - simoncion 4y ago
    > ...it's absolutely possible that the password was obtained through some other mechanism. +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?".
ryan-c 4y ago
The author clearly meant "cracked" rather than "brute forced". 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! would be trivial to guess.
- b112 3y ago
  They used chatGPT, trained on this user's emails, posts, data! (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!)
BeefWellington 4y ago
While I agree in the specifics the overall message still stands IMO: Update your KDF going forward if you care about this kind of security.
zokier 4y ago
Making this bit mor concrete: luks1 uses pbkdf2 with sha1 and minimum iteration count of 1000 as far as I can tell. Looking at random hashcat benchmark for rtx 4090, the closest thing is about 20MH/s. If we assume attacker spends a month with 1000 gpus, they will have bruteforced 20e6×86400×30×1000 combinations. Log2 of that rounds up to 56 bits. https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
- terom 3y ago
  You're underestimating the default PBKDF parameters used by LUKS1, `cryptsetup luksFormat` [1] benchmarks the `--pbkdf` function at runtime when configuring the keyslot, and the default iteration count is based on a target `--iter-time` [2], which is either 1s or 2s [3], unless overridden by the distro. I'm not entirely sure about the PRF (SHA1/256) used by LUKS1, it might be SHA-1 or SHA-256 [4]. 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.8.html https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Iteration_time https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
- deleted 4y ago
  [deleted]
mox1 4y ago
Here's how it works: When the gov wants to crack a password, they gather all of your digital life (phone, computers, thumb drives, etc.) and basically run "strings" on all of the hard drives / data they have of you. 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.
- deleted 4y ago
  [deleted]
- comboy 4y ago
  > They are happy to let it churn for months / years (because the case is working through the system). 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)
  - sandworm101 3y ago
    No. Resources are always limited. Forensic investigators will not be running things on server farms for years. People who think such things really do not understand how many cases are "in the system" at any one time. Even for something relatively serious like CP, drug smuggling or lower-end terrorism, there are literally thousands of cases in-the-system. The server farms infrastructure (ie hiring cloud capacity) would be reserved for national security, foreign intelligence and stopping Magneto. The contents of your laptop are not worthy of such treatment.
- realusername 4y ago
  Not sure how it's done in the US but an effort to crack it like this would happen only on very high profile cases in France which is not the case of this one. I'm betting on the second option, he reused the same password somewhere else or they just got lucky and seized the computer already unlocked
corndoge 4y ago
NSA agent spotted /s
benlivengood 4y ago
English has ~1 bit of entropy per character. Replacing a character with a similar symbol adds ~1.5 bits to that character (there aren't leetspeak substitutions for every letter, so I am being a little generous). Random symbol insertions between words adds ~5 bits per ~5 characters (10 numbers, their shift-codes, and the punctuation, average word length is ~5). If every letter of the password is randomly leetspeak that yields 50 bits. If symbols are inserted between each word (average of ~4 in 20 characters) that yields 70 bits, which is barely greater than the 68 bits of entropy per second equivalent of 300M TH/s
- nickelpro 4y ago
  Please explain the math behind a 26 letter alphabet having 1 bit per character
  - dangerlibrary 4y ago
    I was also skeptical of this claim. It seems to come from Schneier's "Applied Cryptography" and assumes you are using whole words in the password. https://en.wikipedia.org/wiki/Entropy_(information_theory)#cite_ref-Schneier,_B_page_234_6-0 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
  - ravi-delia 4y ago
    Grammatical English is an extremely restricted subset of all strings of characters. You can actually see for yourself that it's in the ballpark of a bit by going to a book, covering up a line, reading the context, and trying to guess the next letter one at a time. I get it 3/4 times, and would probably be down to 1/2 if I had to do it the right way. 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
dhx 4y ago
A previous letter[1] supposedly from the same person stated that he was under surveillance before arrest, and thus "black-bag cryptanalysis"[2] is quite probable, particularly due to SDAT being a well resourced domestic spy agency. "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 https://anarchistnews.org/content/update-letter-ivan-alocco [2] https://en.wikipedia.org/wiki/Black-bag_cryptanalysis https://en.wikipedia.org/wiki/Black-bag_cryptanalysis
deleted 4y ago
[deleted]
8organicbits 4y ago
> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. 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.
CodesInChaos 4y ago
I don't follow your math. If we assume the cost of your password hash matches the cost of a bitcoin hash, I arrive at 2 * 10^6 years, not 4 * 10^39 years. 2^114/350e18/3600/24/365 = 1.9e6 Even 2^114 itself is only 2 * 10^34
- codethief 4y ago
  Yeah, I'm not following that calculation either. Adding to that: > 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"?
- orlp 3y ago
  I... don't know what the hell happened. I was doing the calculation on mobile while on the move and I must've screwed up the parenthesis in the denominator. Embarrassing... 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.
acchow 3y ago
> it would still take you 4 x 10^37 centuries. 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.
- LodeOfCode 3y ago
  The birthday paradox only applies when you're trying to find any pair of inputs with the same output, because then the probability of success scales with the number of pairs ≈ guesses^2. If you're trying to find an input with a particular output (in this case one that results in the same key as their password), then on average you'll have to try half the search space (divided by the number of correct answers in the search space, but that should be one in this case) 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

by orlp 4y ago

mjg59 4y ago

The presumption that 20 characters is any meaningful amount of entropy is based on the password actually being somewhat random, and there's no fundamental reason to believe that that's true. I tend towards brute forcing not being the most likely reason for this, but the indisputable reality is that any combination of weak passwords and PBKDF2 makes it plausible (if not necessarily likely) that an adversary with a sufficiently large hardware budget can break disk encryption.

deleted 4y ago
[deleted]
aborsy 4y ago
You don’t need to merely tend towards. You just can’t brute force a random 20 characters password of the type that he mentioned. Brute force is almost never used, even with half of entropy of such password. His password was intercepted, or was embarrassingly deterministic.
- raverbashing 4y ago
  Or something like, notebook still had the keys in memory when it was recovered 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).
- mort96 4y ago
  I didn't see anyone mention a random 20 characters password. I saw 20 character password with symbols and upper and lower case. That might be 4 words strung together "correct horse battery staple" style.
- mjg59 4y ago
  A stronger KDF would plausibly have protected him even if his password was embarrassingly deterministic.
  - stouset 3y ago
    Maybe. But probably not. 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.
AlexCoventry 4y ago
If the computer is suspended at the time it's seized, does it become easier to recover the FDE key from the computer's memory? Or is that encrypted with the user password, or something like that? (On stock ubuntu, say.)
- mjg59 3y ago
  If you can dump the contents of memory then you have the key (after all, the CPU has to be able to encrypt and decrypt the material, so it has to be available).
  - zamnos 3y ago
    Pedantically, if there's an HSM/similar hardware in play, the CPU only asks for material to be encrypted/decrypted and doesn't have the key in system RAM to be able to do so itself. MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
  - ryan-c 3y ago
    Apparently it's possible to keep the key in the debug registers: https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
- zamnos 3y ago
  If the DRAM is powered on at the time of seizure, recovering the key is eminently possible. If this is an issue for you, completely power off the laptop when transiting customs. https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack

segfaultbuserr 4y ago

> so in the absence of any sort of opsec failures [...] The original sentence already came with this disclaimer.

wallmountedtv 4y ago
Agreed. Annoyingly the author does split up a very core idea to the next paragraph: > 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.
- eduction 4y ago
  Disagree, long paragraphs are more annoying than breaking up thoughts like this. I think it's reasonable to expect a reader to continue to the next paragraph, and corrosive to start writing for poor readers (distracted, skimming, etc - let people who do this bear the risk and consequences of their actions rather than changing writing to make this behavior less risky)
comboy 4y ago
> absence of any sort of opsec failures There is no such thing.

simoncion 4y ago

a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec. 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.

mjg59 4y ago
I don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
- simoncion 4y ago
  > ...it's absolutely possible that the password was obtained through some other mechanism. +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?".

ryan-c 4y ago

The author clearly meant "cracked" rather than "brute forced". 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! would be trivial to guess.

b112 3y ago
They used chatGPT, trained on this user's emails, posts, data! (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!)

BeefWellington 4y ago

While I agree in the specifics the overall message still stands IMO: Update your KDF going forward if you care about this kind of security.

zokier 4y ago

Making this bit mor concrete: luks1 uses pbkdf2 with sha1 and minimum iteration count of 1000 as far as I can tell. Looking at random hashcat benchmark for rtx 4090, the closest thing is about 20MH/s. If we assume attacker spends a month with 1000 gpus, they will have bruteforced 20e6×86400×30×1000 combinations. Log2 of that rounds up to 56 bits. https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...

terom 3y ago
You're underestimating the default PBKDF parameters used by LUKS1, `cryptsetup luksFormat` [1] benchmarks the `--pbkdf` function at runtime when configuring the keyslot, and the default iteration count is based on a target `--iter-time` [2], which is either 1s or 2s [3], unless overridden by the distro. I'm not entirely sure about the PRF (SHA1/256) used by LUKS1, it might be SHA-1 or SHA-256 [4]. 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.8.html https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Iteration_time https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
deleted 4y ago
[deleted]

mox1 4y ago

Here's how it works: When the gov wants to crack a password, they gather all of your digital life (phone, computers, thumb drives, etc.) and basically run "strings" on all of the hard drives / data they have of you. 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.

deleted 4y ago
[deleted]
comboy 4y ago
> They are happy to let it churn for months / years (because the case is working through the system). 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)
- sandworm101 3y ago
  No. Resources are always limited. Forensic investigators will not be running things on server farms for years. People who think such things really do not understand how many cases are "in the system" at any one time. Even for something relatively serious like CP, drug smuggling or lower-end terrorism, there are literally thousands of cases in-the-system. The server farms infrastructure (ie hiring cloud capacity) would be reserved for national security, foreign intelligence and stopping Magneto. The contents of your laptop are not worthy of such treatment.
realusername 4y ago
Not sure how it's done in the US but an effort to crack it like this would happen only on very high profile cases in France which is not the case of this one. I'm betting on the second option, he reused the same password somewhere else or they just got lucky and seized the computer already unlocked

corndoge 4y ago

NSA agent spotted /s

benlivengood 4y ago

English has ~1 bit of entropy per character. Replacing a character with a similar symbol adds ~1.5 bits to that character (there aren't leetspeak substitutions for every letter, so I am being a little generous). Random symbol insertions between words adds ~5 bits per ~5 characters (10 numbers, their shift-codes, and the punctuation, average word length is ~5). If every letter of the password is randomly leetspeak that yields 50 bits. If symbols are inserted between each word (average of ~4 in 20 characters) that yields 70 bits, which is barely greater than the 68 bits of entropy per second equivalent of 300M TH/s

nickelpro 4y ago
Please explain the math behind a 26 letter alphabet having 1 bit per character
- dangerlibrary 4y ago
  I was also skeptical of this claim. It seems to come from Schneier's "Applied Cryptography" and assumes you are using whole words in the password. https://en.wikipedia.org/wiki/Entropy_(information_theory)#cite_ref-Schneier,_B_page_234_6-0 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
- ravi-delia 4y ago
  Grammatical English is an extremely restricted subset of all strings of characters. You can actually see for yourself that it's in the ballpark of a bit by going to a book, covering up a line, reading the context, and trying to guess the next letter one at a time. I get it 3/4 times, and would probably be down to 1/2 if I had to do it the right way. 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

dhx 4y ago

A previous letter[1] supposedly from the same person stated that he was under surveillance before arrest, and thus "black-bag cryptanalysis"[2] is quite probable, particularly due to SDAT being a well resourced domestic spy agency. "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 https://anarchistnews.org/content/update-letter-ivan-alocco [2] https://en.wikipedia.org/wiki/Black-bag_cryptanalysis https://en.wikipedia.org/wiki/Black-bag_cryptanalysis

deleted 4y ago

[deleted]

8organicbits 4y ago

> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. 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.

CodesInChaos 4y ago

I don't follow your math. If we assume the cost of your password hash matches the cost of a bitcoin hash, I arrive at 2 * 10^6 years, not 4 * 10^39 years. 2^114/350e18/3600/24/365 = 1.9e6 Even 2^114 itself is only 2 * 10^34

codethief 4y ago
Yeah, I'm not following that calculation either. Adding to that: > 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"?
orlp 3y ago
I... don't know what the hell happened. I was doing the calculation on mobile while on the move and I must've screwed up the parenthesis in the denominator. Embarrassing... 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.

acchow 3y ago

> it would still take you 4 x 10^37 centuries. 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.

LodeOfCode 3y ago
The birthday paradox only applies when you're trying to find any pair of inputs with the same output, because then the probability of success scales with the number of pairs ≈ guesses^2. If you're trying to find an input with a particular output (in this case one that results in the same key as their password), then on average you'll have to try half the search space (divided by the number of correct answers in the search space, but that should be one in this case) 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