Forum Replies Created

Viewing 15 posts - 1,186 through 1,200 (of 1,759 total)
  • Author
    Posts

  • Svante
    Spectator

    Hi Paddy (& Lucas),

    We will be adding an option for “require password every time”, since it is such a frequent request. We really don’t agree with this, since we think it encourages other unsafe practices such as sharing a Windows Login between different users – even in a family. Nevertheless, it seems like the line of least resistance ;-)

    On the case of passwords stored using AxCrypt, I’d like to point out that with the Premium subscription you’re also getting our Password Manager, which is both less costly and in many ways simpler to use than many other similar services. It is available for use from any device with an internet connection, including mobile devices.

     

    in reply to: AxCrypt 2.1 doesn’t ask me for an encryption password #4954

    Svante
    Spectator

    Hi Neal,

    Your “per-file” option is actually quite an interesting idea. Thank you. We may indeed do just that. Watch https://bitbucket.org/axantum/axcrypt-net/issues/186/add-option-for-requiring-password-every for progress.

    in reply to: Offline decryption #4950

    Svante
    Spectator

    Hello Paul!

    You’re misinformed fortunately. As opposed to Cloudfogger, you can decrypt your AxCrypt files at any time, with or without Internet, and with or without our servers or our business being operational.

    As long as you have a copy of the software (and that’s pretty much spread around the Internet by now), and know the original password you can continue to use and decrypt your AxCrypt-encrypted files.

    in reply to: iOS Mobile Open Beta #4949

    Svante
    Spectator

    Hello Robin,

    You should use the “Erase Data” option if someone tries your passcode too many times. As mentioned, even if we did require the AxCrypt password every time, a phone is such a locked down environment that we could not guarantee it to be clean anyway.

    The iOS level of protection against passcode attempts is actually pretty solid. The FBI did manage to get around it in an old iPhone 4S after several months and paying an undisclosed (but presumably significant) amount of money to a third party to bypass the protection. More recent versions of iOS does not have that particular vulnerability.

    in reply to: AxCrypt 2.1 doesn’t ask me for an encryption password #4946

    Svante
    Spectator

    Hi Neal,

    Thanks for your input!

    They say the customer is never wrong, but to be honest I have a hard time with this rather frequent request. I’m assuming you’ve read https://forum.axcrypt.net/blog/leaving-computer-axcrypt/ which is a longer dicussion about this.

    But, yes, we’ll be adding a number of dangerous options like this one. I really, really think that it tends to reduce security because of the increased threshold of use and the likelyhood of avoiding long and strong passwords. But, we will add it as an option.

    Stay tuned! Now the mobile apps are out, we’ll have more resources to work on the desktop application.

    in reply to: some suggestions for AxCrypt #4918

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    https://play.google.com/store/apps/details?id=net.axcrypt.axcrypt2x

    We also just released AxCrypt Mobile for iOS.

    Thank you for your support.

    Enjoy!

    in reply to: App Development Status #4917

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    https://play.google.com/store/apps/details?id=net.axcrypt.axcrypt2x

    We also just released AxCrypt Mobile for iOS.

    Thank you for your support.

    Enjoy!

    in reply to: Android Mobile Open Beta #4916

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    https://play.google.com/store/apps/details?id=net.axcrypt.axcrypt2x

    We also just released AxCrypt Mobile for iOS.

    Thank you for your support.

    Enjoy!

    in reply to: I can't find my old AxCrypt for iPad…. #4915

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    Now we have released AxCrypt Mobile for iOS.

    https://itunes.apple.com/us/app/axcrypt/id1157695909?mt=8

    Thank you for your support.

    Enjoy!

    in reply to: iPad Air IOS 10.0.2 #4914

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    Now we have released AxCrypt Mobile for iOS.

    https://itunes.apple.com/us/app/axcrypt/id1157695909?mt=8

    Thank you for your support.

    Enjoy!

    in reply to: iOS app version #4913

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    Now we have released AxCrypt Mobile for iOS.

    https://itunes.apple.com/us/app/axcrypt/id1157695909?mt=8

    Thank you for your support.

    Enjoy!

    in reply to: Axcrypt app for IOS #4912

    Svante
    Spectator

    Earlier this week we released AxCrypt Mobile for Android.

    Now we have released AxCrypt Mobile for iOS.

    https://itunes.apple.com/us/app/axcrypt/id1157695909?mt=8

    Thank you for your support.

    Enjoy!

    in reply to: Some questions #4903

    Svante
    Spectator

    Stephen,

    First – you’re partially correct on how an old password can be used to decrypt a file after the key pair is regenerated or otherwise lost. The other thing is that when a file is encrypted, the file master key is also encrypted symmetrically with the password in effect at that time. So, you can always decrypt a file, even without the key pair, if you know the password in effect at the time of encryption. This is a measure to reduce the risk of data loss. The most common cause of data loss in Windows is loss of the key pair associated with the Encrypting File System, EFS. We don’t want AxCrypt to have the same problem.

    Second – When a Premium user sends an AES-256 to a free user, that free user can open it (if (s)he has the password / keypair). If (s)he updates the file causing it to be re-encrypted, it’ll be encrypted with AES-128.

    In summary: Premium: Decrypts all. Encrypts with AES-256. Free: Decrypts all. Encrypts with AES-128.

    in reply to: Some questions #4901

    Svante
    Spectator

    Hello Stephen,

    Well – I can’t say you didn’t do your homework ;-) I’ll try to respond, but to be honest, it’s a little hard to determine exactly what the questions are. But I’ll try. All answers assume that AxCrypt is used in online mode. (There are some variations to the theme in offline mode.) For followups, can you perhaps be careful to distinguish background info and assertions, from the actual questions? I try to answer, but it’s easy to miss something when the questions are not clearly separated and stated.

    Q: Is the encryption password the same as the web sign in password?

    A: Yes, when signed in to AxCrypt, all *encryption* is done using that password which is also the same as the web sign in. See below for details.

    Q: What does password reset do?

    A: It creates a new key pair, and encrypts the private key with the new password. The old key pair is kept around, should you ever change back to the original password.

    Q: Can a hacker change the password to your files?

    A: No. A hacker with control over your email can *reset* the password to the server (see above). This does not change anything or let the hacker open your encrypted files. Once you have regained control over your email, you can reset the password back to the original.

    Q: Can a trial user open/encrypt/modify files key shared with them after the trial expires?

    A: Yes. New encryption operations will use AES-128, but otherwise it all keeps on working.

    Q: Can you change your password and also invalidate the old one for all old files?

    A: No, not really. It’s complicated. See below for a technical explanation of how file encryption works.

    How does file encryption with AxCrypt 2 and AxCrypt ID work?

    An AxCrypt ID is a public key pair, using RSA-4096. The public key is used for encryption, and is non-secret. The private key is used for decryption, and is kept encrypted using your sign in / web password.

    When a file is encrypted, the following operations take place:

    1) A random 128 or 256-bit key is generated. We call this the file master key (or session key).

    2) The file content is encrypted using this master key, and the encrypted data is stored in the .axx file.

    3) The file master key is ‘wrapped’, i.e. iteratively encrypted using AES and a key derived from your sign in password. This wrapped file master key is also stored in the .axx file, as headers and trailers.

    4) The file master key is also encrypted using your AxCrypt ID public key. This encrypted file master key is also stored in the .axx file, as headers and trailers.

    5) (optional) The file master key is also encrypted using key sharing recipients’ AxCrypt ID public keys. These encrypted file master keys are also stored in the .axx file, as headers and trailers.

    When you change your password, your private key is decrypted using the old password, and then encrypted again using your new password.

    When you sign in, the password is verified by attempting to decrypt your private key.

    When you decrypt a file, we first try to decrypt the file master key using your private key (decrypted since you’re signed in). If this works, we decrypt the file contents using the now decrypted file master key.

    If that does not work, we try to use the sign in password to decrypt the iteratively wrapped encrypted file master key as described above. If this works, we decrypt the file contents using the now decrypted file master key.

    If this does not work – we prompt you for a different password.

    in reply to: no verification code #4900

    Svante
    Spectator

    Hello Sander,

    From what we can see you did indeed receive the verification code, since your account is verified.

    You received the verification email about 20 minutes after you initially registered, because this is a requirement from your email provider. They use a spam-limiting function called ‘greylisting’, which means that at the first connection attempt the email is refused, but it will be accepted at a later time. So, when we retried a little later, the mail was accepted and you received it to your inbox.

    This is why there was a certain amount of delay. You should be aware of this behavior with your email provider, and I’m sure that if you think about you’ll recall that sometimes emails are delayed. Your providers’ greylisting procedure is the likely cause in more cases than this.

     

Viewing 15 posts - 1,186 through 1,200 (of 1,759 total)