Decrypting an SD card - best case scenario

Nope, see the catch is a dictionary attack would have to account for all possible patterns of symbols between words and for every symbol combination attempted efficiency drops exponentially. By the time every symbol pattern combination is attempted on a 8-12 letter word it becomes brute forcing.

this, you should raise the actual entropy instead of security through obscurity.
many systems use sha256 nowadays, so you can add entropy up to 256 bits to strengthen your password

Attached: password_strength.png (740x601, 91K)

Thanks. Looking into this now.

That pic is the WORST possible advice for secure passwords I have ever seen. Would take maybe a day at most to crack on my Rx 570.

t. mathlet

lol who uses words with number substitutions though? All my passwords are strings of randomly combined letters and numbers

i selected 4 random words from github.com/first20hours/google-10000-english/blob/master/google-10000-english.txt
concatenated them and hashed with sha256 without salt:
pastebin.com/SsdXrj6H
time to prove your claim

That password is EXCEEDINGLY easy to crack through word based dictionary attacks. There's only about 5-10K english words commonly used in writing and most people using this method would choose the first 1K even more common words for easy memorization.

I'm not going to waste my time but the reason is better is because it turns what SHOULD be a dictionary attack into a brute force one.

>That password is EXCEEDINGLY easy to crack through word based dictionary attacks.
you're more than welcome to try
>There's only about 5-10K english words commonly used in writing and most people using this method would choose the first 1K even more common words for easy memorization.
the one on the xkcd implies the first 2048 words
>I'm not going to waste my time but the reason is better is because it turns what SHOULD be a dictionary attack into a brute force one.
you're spouting nonsense. what really matters is the total entropy. more entropy always results in better password, regardless the way you achieve it. the 4 top2k word one has roughly the same entropy as a random alphanumeric string of 7 characters. please learn mathematics before posting again.

>what matters is entropy
>even though it makes it extremely easy for dictionary attacks to narrow down combinations to 0.000001% of all total combinations and them heuristically try those
k

how on earth would you narrow them down?

To all those people saying that adding a character between a word isnt secure I implore you to crack this string

19ba605f5ed88db2e5d9de44e63db823cecc2ca90747aa71f70ad976c1d52ff8

Its a random word from a dictionary with a random character in between letters and encapsulating the word. There's no chance of you getting it.

not from top 10k words. have to run a bigger dictionary on it, but stay tuned. unfortunately i can only work with a laptop gpu rn

(Me)
nvm took less than expected:
?s?t?r?i?k?e?b?r?e?a?k?e?r?

oh shit thats pretty cool, whats the process and on what hardware. you sure showed me.

well fuck

#include
#include

int main()
{
std::string str;
while(std::getline(std::cin, str))
{
for(auto i = 0u; i < 128; ++i)
{
if (!isprint(i))
continue;

const auto ch = char(i);
std::string outs;
outs.reserve(str.length() * 2 + 1);
outs += ch;
for (auto c : str)
{
outs.push_back(c);
outs.push_back(ch);
}
std::cout

interesting. I wonder how long it would take if their was no known encapsulation/ characters between the word. Either way I could see it being run in a concurrent attack

BTFO

Given the computational prowess of modern day GPUs like a V56 (10+ FP32) are random 16 char passwords even safe anymore assuming only a desktop is used for the attack?

Love how he brown nosing after grand standing lol

entropy for a single password doesn't exist, retard. it's the entropy for a password selection algorithm.

Yeah I'm pretty salty desu, thought it would turn a dictionary attack into a brute force one or near that. Though given all this hardware muscle recently it seems like soon even a random 32 char passwords won't be enough.

Attached: baka.jpg (1920x2159, 256K)

completely random passwords (as in, generated with a proper random password generator) are safe. i always make sure my passwords are 64 characters long to be sure, or if the website doesn't allow 64 characters, whatever their maximum is

user's password had roughly 25 bits of entropy (log2(44000000)) while a random alphanumeric string of 16 characters would still have about 96 bits of entropy, which is far more. If you want to be super safe, max out the 256 bits of entropy sha256 retains and go for 43 characters. going for more like is pointless due to collisions since everything will collide into the same 2^256 buckets

Really impressive!

btfo

why 43 characters? 43*8 = 344 which is greater than 256, so technically the max would be 32 characters, no?

wanna see you type a null in your password

um what?

you calculate 8 bits per character, while majority of them cannot be used. calculate with 6 bit per char for a nice number, or log2(whatever amount of chars can be in a password on the site) for exact number

Attached: ASCII+Table.jpg (960x720, 211K)

why log2()? where do you get that from?

because you'd want bits. essentially you use base 64 and want to convert that to binary and calculate how many base 2 digits a single base 64 digit will occupy. the answer is log2(64), which is 6. if you use base 95 (which is the amount of printable ascii chars) one digit will take log2(95) binary digits to write, which is about 6.56. 256/6.56 = 39.02, so you'd need 40 characters of this to fill all the entropy sha256 retains.

id assume something to do with binary representation

ah i see, thanks for the explanation

Haha this is the best troll ever

Not any of these anons but how weak is using a string of words vs a single word with symbols placed between each letter? Are they both equally useless if you had both methods included in your concurrent dictionary attack?

No dumb dumb, it's the entropy that matters, not the amount of chars. If you have a method to create your passwords then you should use one that maximises entropy, like in the xkcd cartoon.

if you know the method all that matters is the entropy input, which is clearly much higher for the four random word one (just make sure the words are true random picked with uniform distribution. just get 2^N words, do N coin flips, and you have it. if you select M words this way, you'll have an entropy of N*M)

A string of words is better, as you have more possible combinations.

But that method makes it really easy to guess doesn't it? There comic itself says to use easy to remember words in a sequence. That's only like 5K words at most used in 4-6 sequences. Sounds pretty ditionary-attackable to me.

No it's not, there are more words that exist than letters.

But by using this method you're turning one of the 5K most memorable words into a char essentially. Now you only have to guess 5K^4 or 6, right?

yes. now I'll let you calculate how much 5000^4 is

Omg user you are right it's more possibilities than all ASCII 8 char combinations!

OP here with a short update. I have the LUKS header information and have been successful with a few hashcat examples so going to tackle the real thing soon. Wish me luck!

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 9f da 0d 21 44 08 16 c0 2d cd 15 c1 7a 27 95 4b 53 61 ce 39
MK salt: b6 8d 1e 87 f3 41 f6 e8 1a fe 52 f0 4a 6c 12 09
7c ec 9b 00 14 ee f0 80 c8 5d 01 1b 68 01 11 42
MK iterations: 103875

Interesting, I thought hashcat was hash only until now.

LUKS has hashes.
regardless, hashcat can do known-plaintext attacks on some ciphers too

post some when you're finished :^)

I know, but I always figured it wasn't smart enough to just process a header dump.