>>1727801

>>1784612

>>1727647

>>1721051

>>1719772

>it decompressed because it doesnt give an error thats how linux works

I've not yet seen any evidence that decryption succeeded. I think aes-256-cfb encoding doesn't have a way for OpenSSL to know if the key is good or not. With "aes256" (aes-256-cbc) shows rejection when you try the key. I tried myself with many different encodings / key variations before coming to this thread. Since "-aes256" is a valid argument to OpenSSL, commonly used, and the insurance file's file extension, I'm inclined to think it was the encryption method used.

Try putting in a different key with aes-256-cfb. Any key at all. No complaints.

# For example, this has the "Berlin?..." key. No complaint from OpenSSL.

$ openssl enc -aes-256-cfb -d -in wlinsurance-20130815-A.aes256 -out ./wl-a3 -pass file:wl-A.pass

$

# Lets change the key to something we know is wrong. Again, no complaint from OpenSSL.

$ echo "Hello World" wl-A.pass

$ openssl enc -aes-256-cfb -d -in wlinsurance-20130815-A.aes256 -out ./wl-a3 -pass file:wl-A.pass

$

Also, the first 8 bytes of the wlinsurance-20130815-A.aes256 file say "Salted__", followed by another 8 bytes for the salt. This is typical of a file generated by OpenSSL. The file that results from decryption using the "Berlin?" key (and the variant with a "^") does not have this, or any other recognizable file signature. You can see the first 16 bytes of a file with

$ head -c 16 <filename>

For all of "The Q" / "The Traveller" poster's rambling boastfulness, I'd think they would have taken a moment have posted decryption instructions. The writing style also seems off. It looks to me like those reddit posts are disinfo / a troll.

>>1788080

>>1811896

I can imagine someone may want to make it tough to tell if a brute force succeeds by going for maximum obscurity. However, I don't believe this is the case here. Having the file begin with "Salted__" points to OpenSSL being used, and what the salt is.

I'm thinking JA chose a strong enough passphrase to where he wasn't worried about brute force. It's not a big leap to assume he went with "aes256" encoding, which is the file extension's name. OpenSSL's implementation indicates an error when a wrong key is supplied for "aes256" (aes-256-cbc) decryption.

With a few steps, you can easily see that an error happens when you supply a wrong key for aes256.

# Create a sample life insurance file

$ echo "This is my secret info. Shhhh." secret.txt

$

# Encrypt the sample file with "aes256" encoding (aes-256-cbc)

$ openssl enc -aes256 -k "correct key" -e -in secret.txt -out secret.aes256

$

# Attempt to decrypt the file with a wrong key.

$ openssl enc -aes256 -k "a wrong key" -d -in secret.aes256 -out decrypted-secret.txt

bad decrypt

139937720559256:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:

$

# Decrypt the file with the correct key

$ openssl enc -aes256 -k "correct key" -d -in secret.aes256 -out decrypted-secret.txt

$

# Since there was no complaint from OpenSSL when using the correct key, lets see what we have…

$ cat decrypted-secret.txt

This is my secret text. Shhhh.

$

If JA wanted the encoding secret, he could have chosen any file extension, or even no file extension.

Even if a malicious state-sponsored actor could successfully crack his AES-256 key (doubtful), maybe JA isn't concerned if they discover it. Assuming the material incriminates the malicious actor, they wouldn't want to reveal it to the public either. It wouldn't suprise me if JA secretly sent decryption instructions to his enemies. My guess is that there is no inner layer of encryption, just a zip file or something like that.