[AxCrypt SupportModerator]

Hi Stephen,

Yes, the fix is in and will be released next week. Thanks! If you’d like I’ll be happy to give you 3 months Premium as a small bug bounty token of appreciation.

You should interpret the 50ms / full keywrap as being equivalent to targeting a cracking speed of 20 passwords / seconds in the target system, using our code – which is not speed optimized in the sense for example hashcat is which can use GPUs for much higher throughput.

The target of 20 full keywraps / second is set so that in normal use and even on a much slower system (think mobile), it will still be fast to actually use for a user. We don’t want a multi-second delay to open a file for regular users.

So it’s a compromise between usability and strength. But, at a target of 20 / second, and lets say you can with GPUs, some work and a decent amount of money can reach 500x that speed, you’re at 1000 / second. That’s still pretty slow. If you use a password such as that recommended by us via our password generator ( the most complex ones we suggest are at approximately 75 bits ).  At 1000 / second, a crack will average a little under a trillion years. With a national security level budget you could perhaps increase that by a factor a million, in which case a single crack will average a little under a million years. For the type of use AxCrypt is made for (private and commercial information security), we believe it’s reasonable.

[AxCrypt SupportModerator]

Hi Tim,

Nope. Or, rather, it depends on the situation. But here he’s using “Password2” to sign to AxCrypt, while the files are actually encrypted with “Password1”. Resetting will seem to have the same effect in this particular case, while slightly different things are happening beneath the hood.

It’s not clear how Robert “entered Password2 as his password”, but it might be that there was an upgrade to AxCrypt 2 at the same time.

In any case, one should always use the *change* password when the current password is known.

[AxCrypt SupportModerator]

Hello Stephen,

Thanks for contacting us.

First of all, the web site documentation was wrong. The minimum is 5000, and typical values are between 25000 and 100000. The reason is the editor inherited this text from the old site, it’s essentially a copy-paste issue. It is now updated.

The minimum of 6 is lower down in the code, in the actual specifications of the key wrap. The higher levels enforce a minimum of 5000.

Now, more importantly, reviewing the code we note that the speed determination is slightly incorrect. The intention is to do batches of 1000 iterations until half a second has gone, and then use that to calculate the effective speed. The current code includes the key derivation in each such 1000 iterations – which in itself also includes a 1000 iterations of a hashing function. The net effect is that our calculation is off. But it’s still at least 5000.

The part of 1 second / 2 second delays you’ll have to explain, because I don’t follow the reasoning. The idea is that performing the total number of key wrap iterations, should take approximately 50ms.

[AxCrypt SupportModerator]

Hello Robert,

You should ask him to *change* his password to Password1. There is a menu option for that in the program.

[AxCrypt SupportModerator]

Thank you Rodney, just so!

[AxCrypt SupportModerator]

Thank you Harold,

I agree with your assessment. Robert, if you still have a problem, contact our support.

[AxCrypt SupportModerator]

Thanks Freddy!

I’ve added that comment to the Bitbucket issue.

[AxCrypt SupportModerator]

Hello Anonymous,

We’re hoping to get a Mac beta out this week, or early next week.

[AxCrypt SupportModerator]

Hello Mark and Arthur!

We don’t activate Premium automatically in the app anymore (we used to, but for some reason this annoyed some users, so we changed that).

The missing “Try Premium” is a bug! Thanks for reporting that, we’ll updated shortly.

[AxCrypt SupportModerator]

Hello Wonderwonder,

Yes, that’s the way it’s designed, to keep the number of passwords down to a minimum of one.

[AxCrypt SupportModerator]

Hello Scott,

If you are using AxCrypt 2 to open AxCrypt 1-files encrypted with a different password than your sign in password, you’ll be presented with a dialog which allows you to specify a key file as well after klicking the “More…” button.

[AxCrypt SupportModerator]

Hi Todd & RobertM,

Encrypting the “actual folder” is a much different type of operation, and has different behavior in many ways than encrypting the files. AxCrypt is likely to remain a file encryption software for the forseeable future.

Encrypting & anonymizing in one step might be supported in the future, although we really do try to keep the number of options down…

[AxCrypt SupportModerator]

Hello Håkan,

If you do not remember the password to your account, you can always reset it. This is not a way to recover encrypted files! It’s only to allow you to sign in to the AxCrypt app and web. The new password will be used to encrypt new files. Go to https://account.axcrypt.net/Home/PasswordReset to do this, or you can also go there from AxCrypt with File | Options | Password Reset .

[AxCrypt SupportModerator]

Hello Dean,

Sorry to see AxCrypt take the blame here, because it’s not an AxCrypt problem. You have asked windows to associate a TurboTax file with Adobe Acrobat Reader. Not AxCrypt. AxCrypt can’t do that.

The screen shot clearly states that Adobe Acrobat Reader is trying, and failing, to open “2016 Hauser D Form 1040 Individual Tax Return.tax2016”. That’s not a PDF file. It does not end with “.pdf”. It ends with “.tax2016”.

See for example https://fileinfo.com/extension/tax2016 .

All kinds of files such as Word Files, PDF files, JPG files, TurboTax files, AxCrypt files etc contain information that only the respective (or compatible) application can interpret and present to you as the user. For example, TurboTax cannot open an AxCrypt-file. AxCrypt cannot open a Word file, or a TurboTax file.

AxCrypt opens AxCrypt-files.
Word opens Word-files.
Acrobat Reader opens PDF-files.
TurboTax opens TurboTax-files.

The way the operating system knows what to do with a file when you double-click it is by ‘associating’ the file extension with the correct application. So:

AxCrypt should be asssociated with “.axx”.
Word should be associated with “.docx”.
TurboTax should be associated with “.tax2016”.
Acrobat Reader should be associated with “.pdf”.

If Windows doesn’t know what to do with a file, let’s say ending with “.tax2016”, it’ll ask you as a last resort:

Now, that’s a pretty dumb suggestion by Windows, both suggesting Acrobat Reader, and suggesting you make this the default for the future. Nevertheless, that’s not an AxCrypt issue.

If you click ‘OK’ here, you’ll get the result you sent a screen shot of, because you have now asked Windows to try to use Acrobat Reader to open something that is in fact a TurboTax File, not a PDF file.

The solution is *not* to rename the file to end “.pdf”. You’ll get the same result.

In this case, you need to ensure that you actually have TurboTax installed – only TurboTax (or possibly other compatible software, which Acrobat Reader and AxCrypt are not) can open TurboTax-files. Once it’s installed, you also have to ensure that the file association above is correct, which it might not be since you now have established an override over the default.

If you find this confusing, please don’t blame AxCrypt! We did not design this system. Microsoft did.

[AxCrypt SupportModerator]

Hello Roger,

We should definitively warn (actually not accept) forbidden folders as watched folders. If it’s any consolation, they should be ignored since they are on the forbidden list. But they should not even be accepted. See https://bitbucket.org/axantum/axcrypt-net/issues/298/secured-folder-should-forbid-adding . Thanks!

As for SSL thumbprints, the thumbprint is not intended to be used for security, but for reference (i.e. to easily identify which certificate to use from a certificate store etc). You should only validate the certificate based on the trust.

An attacker can’t “inject fake tumbprints in real time”, it’s just a hash of the certificate, it’s not an integral part of the certificate.

Still, it doesn’t hurt, but the important part is really that it’s issued by the correct trusted authority. If you’d like to protect against various forms of man-in-the-middle scenarios, you should verify that it’s issued by the right authority – not any authority that your computer happens to trust, which may be more than you want – perhaps due to an attacker or your company having injected their own root certificate as trusted.

Anyway, see the updated https://forum.axcrypt.net/cryptographic-hashes-files/ .

[Author]

Posts