AxCrypt v2
#11
Well, the user should probably know it. The distinction is quite clear: only paid/premium users get the AES-256 support (at least for the time being, in the current version).
Furthermore, some users might remember what cipher was written there (the screenshot above shows that it's quite highlighted in that list what algorithm is used, but I guess some users just don't give attention to it... that might also the problem that you didn't noticed that the 2 files were different, one was crackable by JTR, the other was not... but the AxCrypt list should have made this clear that the "AES-128" vs "AES-256" is different).

Yeah, most hash crackers do not allow trying 2 very different algorithm at the same time... I think it's still best to say: if you really have no clue if "AES-128" or "AES-256" was used, just think about if you paid for the premium version... and if in doubt always try the AES-128 cracking first and if every attempt fails, try with AES-256. I think that is kind of an acceptable strategy and is still very flexible (because if the user knows for sure that AES-256 was used because of the pro version, they do not need to try the other one and the algorithm also internally doesn't try both, which would be a waste of time/resources).

Thx

BTW: just forget to add this: for the AxCrypt software itself it's basically a no-cost operation to test both ciphers (AES-128 and AES-256)... it's not that of a waste and somehow obscures the underlying algorithm (some people think that fact makes it more secure, but it's very doubtable in this case... in other cases like full disk encryption - FDD - it sometimes makes a little more sense, because the data could be also a completely random data and not as obvious as a .axx file, where it is quite obvious which ciphers are supported or not... in the FDD case, some security guys think it's a good idea to "hide" the hashing or cipher (like in VeraCrypt/TrueCrypt) because of properties like https://en.wikipedia.org/wiki/Deniable_encryption , but at the end, the number of possibilities and options is always quite limited, so you "just" have to try with several different configurations).
Reply
#12
Well yes, having AxCrypt and both the files is easy to spot (even tho I did not realised ride away). It would make it perfectly doable to just choose the v2 AES-### used.

Probably in an offensive situation (red teaming/pentesting), having just the .axx file, would be probably very time consuming. But even in that case it might be possible to find some info on whether the company has a premium/company account (which might be highly probable).

Thanks for all those explanations.
Reply
#13
https://hashcat.net/forum/thread-9434.html

The link above refers to my earlier query. My files are AxCrypt 1 (free version) so will be AES128.

Does this confirm that Hascat and JTR won't therefore be able to decrypt them?
Reply
#14
The AxCrypt 1 version of hashes that hashcat already supports (-m 13200) is only using AES-128: https://github.com/hashcat/hashcat/blob/...re.cl#L169

I'm not totally sure if AES-256 could be used for AxCrypt 1 too, but I'm pretty sure that hashcat only supports AES-128 for AxCrypt-1 as you can see from the code above.

Maybe you, TomM, can also do some further research and investigate this and create some further new test examples and test other hashes that create $axcrypt$*1* hashes with axcrypt2john.py ? But again, maybe it's off-topic here and the AxCrypt 1 problem should be discuessed in the other thread ? Thx



update: It seems AES-256 is/was not supported with AxCrypt 1 see : https://bitbucket.org/axcryptab/axcrypt-...re/Crypto/

There is no "V1Aes256CryptoFactory.cs" (or in general no Aes256 with V1), only for V2 there are AES256 program files . Of course this assumption is not bullet-proof (there could still be the slight possibility that one version supported it in the past etc... but it's very unlikely... but I would still contact the AxCrypt support if you are really in doubt and maybe mention their answer here etc). Thx



BTW: I think this code and comment (that I accidentally found now while searching for the AxCrypt 1 supported ciphers) does indeed hint that the cipher does not occur in the .axx file metadata, but every "CryptoID" or algorithm is just tested one by one until a hit or each and every one of them failed: https://bitbucket.org/axcryptab/axcrypt-...es-111:112
Reply
#15
Ok well so that makes it impossible to know the cipher just having the .axx file. I was actually trying to compare two pro-encrypted files with two free-encrypted files but I did not get anywhere with that.
Reply
#16
okay, I will probably start to implement this, starting with the AES-128 variant.

Not sure how long it will take and if it will be merged into hashcat (and available in beta) soon.

But I will take the challenge and try to implement it... from a technical perspective the "most difficult" part is the 2 heavy loops which are kind of uncommon for other hashing algorithms (but we already have some examples of them)... We would need two heavily iterated loops (both for PBKDF2-HMAC-SHA512 and the AES unwrapping loop).

The good thing is that axcrypt2john will still be able to extract the data of both of them so we do not need to wait for an update there... but it's still important that the users selects the correct hash type in hashcat (when it will be available) otherwise it will be uncrackable of course (well, the user could find out that this algo is wrong and move on to the other variant).
Thx



update: I proposed this change for the hashcat source code (both new AxCrypt 2 algos): https://github.com/hashcat/hashcat/pull/2517
We could/would need to wait until reviewed/accepted/merged and new beta is available... in theory you could always test it also by building it from the source code yourself in the meantime. thx
Reply
#17
(08-14-2020, 11:06 AM)philsmd Wrote: okay, I will probably start to implement this, starting with the AES-128 variant.

Not sure how long it will take and if it will be merged into hashcat (and available in beta) soon.

But I will take the challenge and try to implement it... from a technical perspective the "most difficult" part is the 2 heavy loops which are kind of uncommon for other hashing algorithms (but we already have some examples of them)... We would need two heavily iterated loops (both for PBKDF2-HMAC-SHA512 and the AES unwrapping loop).

The good thing is that axcrypt2john will still be able to extract the data of both of them so we do not need to wait for an update there... but it's still important that the users selects the correct hash type in hashcat (when it will be available) otherwise it will be uncrackable of course (well, the user could find out that this algo is wrong and move on to the other variant).
Thx



update: I proposed this change for the hashcat source code (both new AxCrypt 2 algos): https://github.com/hashcat/hashcat/pull/2517
We could/would need to wait until reviewed/accepted/merged and new beta is available... in theory you could always test it also by building it from the source code yourself in the meantime. thx

That's very good news. Thanks for your work, I will play with it as soon as possible Smile

____

Update : Just tested both the modules (23500, 23600) and they worked perfectly. About performance I got ~10500H/s for -m23500 and ~7778H/s for -m23600 per gpu (gtx 1070 mixed brands).
Reply
#18
Thanks for testing. The new beta is now available that includes the new support for AxCrypt 2: https://hashcat.net/beta/ .
Of course, every upcoming release version greater 6.1.1 will also include the support for the new hash type.
Reply