Forum Replies Created

Viewing 15 posts - 526 through 540 (of 1,759 total)
  • Author
    Posts
  • in reply to: install issue – unhandled exception #8212

    Svante
    Spectator

    Hello David,

    Can you please send the information specified here: https://forum.axcrypt.net/blog/send-complete-error-report/ to our support email?

    Also, please ensure that you have the most recent version of AxCrypt from https://forum.axcrypt.net/ installed.

    in reply to: Unable to decrypt incoming file #8200

    Svante
    Spectator

    Hello QT,

    The message “you are already signed in with this password” means just that. AxCrypt already tried to decrypt the file with the password you’re signed in with, and since that did not work prompts you for the file password. You’re then entering the same password again, which is not going to work, since that password is already tried and found lacking.

    You need to know the password actually used to encrypt the file. It’s not the one you’re using.

    If you want to share encrypted files with others, the sender will need to add you as a recipient using the shared key feature. Then you can open the file with your own password. In this scenario, the problem is not on your side, but on the sender side. They will need to explicitly allow you access to the file (which makes sense, right, since where would the security be if any encrypted file could be opened by anyone receiving it?).

    You’ll find documentation and instruction videos via https://forum.axcrypt.net/ .

    in reply to: Using AxCrypt on shared access database #8198

    Svante
    Spectator

    Hello Anonymous,

    Using AxCrypt to encrypt and work with a shared Access database is not a good use case I’m afraid.

    It can absolutely open a read/write copy (I don’t know why yours is read-only, probably because the file is read-only, but it’s hard to tell). But it’s still not a good idea, since what AxCrypt will do with the shared encrypted file is to decrypt it locally, then you’ll be working with it locally, and then update it all when you’re done. This means if two persons are doing this at the same time, the first one to save and quite will lose his/her changes when the second one saves and quits.


    Svante
    Spectator

    Hello Amy,

    Well that explains it! Windows can only load files that are 2GB or smaller as .exe . That’s a built-in limitation of Windows and how it works with executable images.

    All should be well now, good luck!


    Svante
    Spectator

    Hello Amy,

    Ok, that means that your computer is able to run the software. It should have been able to run the encrypted file as well – unless it’s very, very large… Is it over 2Gb? In that case, it’s not corrupted, just too large to run and you’ll be able to decrypt it fine with AxDecrypt if you have the correct password.


    Svante
    Spectator

    Good enough, that’s not the problem anyway then.

    Perhaps the file is in fact corrupted. Please browse to http://www.axantum.com/AxCrypt/Downloads.aspx and then chose the ‘AxDecrypt.exe’ download you’ll find there. That’s actually the exact same software that’s part of the self-decrypting exe, just without any payload. It, however, has the capability to decrypt another file even when it’s an ‘exe’.

    It has a very sparse user interface, but if it runs ok, use the File | Open menu, then select “*.exe” as the file type to open and then find and select the file you’re trying to decrypt, and then click ‘Decrypt’.


    Svante
    Spectator

    Hello Amy,

    Can you go to ‘This PC’ and check properties and report what it says under ‘System’? Here’s a sample of how it can look:

    This PC


    Svante
    Spectator

    Hello Amy,

    This message typically is displayed when the architecture does not match, i.e. trying to run a 64-bit software on a 32-bit operating system. However, the self-decrypting files are 32-bit.

    Are you perhaps running Windows 10 on a tablet or a similar non-desktop?

    in reply to: losing file updates #8153

    Svante
    Spectator

    Hello,

    I can’t be 100% sure about what your user name is, but I’m guessing it’s something like “so*******ld@gmail.com”. If this is correct, you may want to start by updating AxCrypt to the most recent version from https://forum.axcrypt.net/ .

    Regardless, you should be aware that saving under a new name from withing Excel can indeed lose you the changes made, since we don’t do anything with files saved under a different name. If you save it in a different location, we have no idea about that either – we literally can’t see what you save where from Excel, except in theory if it’s to one of the folders monitored by AxCrypt.

    If you want to save a copy, ensure you do so in a place you know where it is, and also that you subsequently encrypt it, or save it to a secured folder location where AxCrypt will see that it needs encryption and will do so when you exit or you click the red ‘clean’ broom icon.

    in reply to: Does AxCrypt encrypt voice #8151

    Svante
    Spectator

    Hello Magaly Montaña,

    AxCrypt will encrypt anything that is stored as a file in your file system.

    Best way to get the best answer is always to try! It’s free and even Premium is free for a month.


    Svante
    Spectator

    Hello Aaron,

    You pose a very relevant question.

    What we actually do on the server at this time, is to use the password manager encrypted XML as a vehicle to verify the password. We don’t actually decrypt or necessarily even keep a password manager file around, but instead in our handler for a sign in, we try to decrypt a “dummy” encrypted XML. If it succeeds, the password is verified. We’re not worried that this is a bad or insecure approach, but as mentioned in the original post, all security analysis is eased if complexity is reduced, so in the future we’ll be using the encrypted private key instead.

    If you’re offline using a desktop app, we use the private key and we check to see if we can decrypt the private key AxCrypt-file in order to verify the password.  We don’t actually decrypt it – we just verify that we can.

    Exactly how this is done is explained in the technical documentation of the AxCrypt file format. Briefly: All AxCrypt-encrypted files are encrypted with a random key uniquely generated for every time a file is encrypted. This key, the “session key” as it were, is then encrypted using the NIST AES Key Wrap algorithm using your password (and if it’s a normal file, also with your public key). So what we do when we encrypt the private key is we encrypt it with a random key, then encrypt that key with the NIST AES Key Wrap, and to verify we just attempt to unwrap the session key. The key wrap is self-verifying, so we’ll know if we get the right session key, and thus if the password is correct.

    So, in either case, we don’t actually need to decrypt the private key in order to verify the password.

    in reply to: error inflating: invalid literal / length code #8139

    Svante
    Spectator

    Hello Jumi,

    I don’t quite understand. If the file was on an external drive, and it was disconnected – that would certainly explain why the encrypted file is damaged. But not how the original file was deleted. If it was on the same disconnected drive (and AxCrypt via the UI does not support encrypting to a different drive), the original can’t even in theory become deleted by AxCrypt – the drive is no longer connected!

    If you did re-connect the drive, and then manually deleted the orginal, that of course would explain it.

    And, sorry, no – there’s no way we can extract 599Mb from 16Mb…. With try broken file you should be able to recover the first aprox 16Mb, but that’s only about 2.5%…

    If you actually did manually delete the original, there may be a chance that a regular undelete utility can recover it from your drive, provided you’ve not used the drive much or at all since the deletion.

    in reply to: Comportement curieux #8138

    Svante
    Spectator

    Hello khaldein,

    Please see the previous responses in this thread.

    in reply to: ouverture du fichier sans ecrire mon code #8136

    Svante
    Spectator

    Thank you, Marc!

    in reply to: Wrong Password (Its NOT the wrong password) #8135

    Svante
    Spectator

    Hello nobody,

    From your account we can see that you seem to have been using the old AxCrypt, at least as far back as 2014. Then in August 2017, you upgraded to version 2, and then reset the password to your online account. On that same day, you also changed password once.

    If the file was encrypted on or before August 4, 2017, the likely problem is that it was encrypted with a password different from what you thought. The old AxCrypt would happily allow you to use any number of passwords, including wrongly typed ones (as long as you did it consistenly twice in a row, which is easier to do than one might imagine). It just to avoid this that AxCrypt 2 works a little differently and only allows one, verified, password to encrypt files.

    Check the ‘Last Modified’ date of the file in question.

Viewing 15 posts - 526 through 540 (of 1,759 total)