Forum Replies Created
-
AuthorPosts
-
Hello Rob,
Criteria, yes, I believe.
Validated, no.
We could with reasonable effort use for example a FIPS 140-2 validated version of Crypto++ for cryptographic primitives, but we don’t support it currently.
March 19, 2017 at 20:07 in reply to: When an encrypted movie is played does it all have to dycrypt before it plays? #5772Hello MickyD,
Sorry, no I don’t know of any encryption product that would support your streaming decrypted data from the cloud scenario – except of course cloud storage provider provided encryption, but it kind of defeats the purpose.
Hello Kirk,
This is indeed so. AxCrypt 2 can open AxCrypt 1 files (and will upgrade them to AxCrypt 2), but AxCrypt 1 cannot open AxCrypt 2 files. This is clearly stated on the download page:
I suggest you download the *standalone* AxCrypt 2, decrypt the files, and then re-encrypt them with AxCrypt 1.
Hello John,
Examining our logs, we find that you appear a little confused about your email-address ;-) Sometimes it’s …list…, sometimes it’s …misc… (the rest redacted for your integrity). You may have both of these for email, but not in our system.
Please check so you’re using the right one (appears to be …list…), and then check if you may not also be mixing up passwords.
Hello Anonymous,
This depends on the version of AxCrypt you’re using – but it also signifies a serious problem with the file. The meaning is essentially that the file has been modified after it was encrypted. That’s not good.
You can’t really ‘fix it’. With AxCrypt 1.x you can chose to ignore it, but no guarantees are given as to the correctness of the decryption. Go to http://www.axantum.com/ and check the section on registry settings for instructions how to instruct AxCrypt to ignore the error.
March 18, 2017 at 15:48 in reply to: When an encrypted movie is played does it all have to dycrypt before it plays? #5760Hello MickyD,
Yes, the entire movie is decrypted before playing – AxCrypt is not always optimal for encrypting/decrypting large streaming media since the decryption process does not support streaming consumers such as video players.
That it’s faster the second time is due to AxCrypt not having cleaned up the decrypted file. You should have a red ‘Broom’ icon in this case, and if you over over it you’ll see an explanation. AxCrypt cannot wipe and delete the decrypted file until it’s sure that it’s no longer being used by the ‘receiving’ application, and sometimes this even means you have to manually tell AxCrypt when is a good time to clean up by clicking the broom when red.
Hello Richard,
Please take a screen shot of the situation.
How to take a screen shot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .
March 16, 2017 at 22:41 in reply to: Encrypting multiple files different passwords using version 2 #5755Hello Brian,
You are welcome. Although we try to make AxCrypt about real security within well-defined boundaries, if we can provide both real security and a good feeling, we’ll try to do so.
Hello Raphaela,
AxCrypt 2 works better with OO, because it has a semi-manual handling of closing files.
The command line parameter documentation for AxCrypt 1 is found at http://www.axantum.com/ .
March 16, 2017 at 22:00 in reply to: Encrypting multiple files different passwords using version 2 #5752Hello Brian,
Thanks for your input! I think the most common problem here is not really using different passwords or not, but the AxCrypt 2 behavior of remembering the password so you don’t need to / have to type it every time. This existed in AxCrypt 1 as well, but was optional (“Remember this passphrase for decryption”).
We’ll be adding an option to require the password for every time a file is opened, not because we really think it’s a good idea or necessary, but by popular demand ;-)
Hello,
No, SSL cannot be intercepted by anyone in a privileged position – unless you by that mean you, yourself or someone else with administrator permissions on your local PC who can install any certificate in your certificate store to mount a man-in-the-middle attack. But this entity does not need to break into SSL! Anyone with admin permissions on your system can get at your secrets there in a number of easier ways. Corporate firewalls cannot terminate an SSL-connection without you being aware of this, and if they instead mount a MITM “attack” we’re back at previous argument. A trusted root certificate needs to be installed in your device.
SSL *is* used to protect both secrets and economic resources. Very few will use VPN to connect to their Internet bank.
You have tested the wrong site, http://www.axcrypt.net – no secrets are ever passed to that server (that being said, we’re in a continuing discussion with our hosting provider about that. It’s a known issue, but not really relevant to this discussion).
The correct site account.axcrypt.net , which currently receives a ‘B’ rating, due some minor issues that may be caused by the user having older browsers. This is a tradeoff between what users are allowed to connect. If we set up too strong a cipher suite, some users with older browsers can’t even connect. Users with modern browsers will not use the older problematic ciphers. But thanks, we’ll take another look at this and see if we can setup a suitable cipher suite giving us the ‘A’ rating, without locking out users.
Adding another layer of security may, or may not, increase the level of security. We may indeed do so in the future but adding layers also increases complexity and difficulty of analysis. Peer review is great – but it’s not a guarantee. There have been problems found in just about any protocol ever published, and the advantage of SSL/TLS is that there are literally thousands of researchers trying to find flaws, and publishing when they do. And they’ve been doing this for a long time.
Better the devil you know, than the devil you don’t still applies.
Hello Pedro,
Yes, I read the list, and much of it is indeed sound advice but it must be taken in context.
The truth is far from “anybody in a privileged position could log the password“. That’s simply not true. Period.
The various leaks and errors made in SSL have been adressed one after another, as they are revealed. That’s not to say there aren’t any more – but it is to say it’s not that easy to design a secure protocol and I’d much rather use a well-known fixed protocol, than a less used and less analyzed, and less fixed protocol. Even worse – make up my own.
That a protocol has no known leaks does not mean it’s secure. That’s the problem with security. You can’t typically prove security, only demonstrate insecurity.
Properly used SSL/TLS is still trusted to protect a majority of world secrets, and world economic assets – and in general does a pretty good job of it, since both you and me and perhaps a billion of other users still have our money in our respective bank accounts without it being stolen by way of a hacked SSL/TLS connection with our banks for example.
The incentive to successfully hack and intercept an arbitrary SSL/TLS connection in economic terms is absolutely gigantic. It hasn’t happened. That’s one reason I trust SSL/TLS for AxCrypt use.
If, however, you have any indication that we’re not using SSL/TLS properly (no one is perfect) – please let us know and we’ll fix it immediately.
Hello Pedro,
It’s always hard to separate conspiracy theory from real vulnerabilities in these scenarios. Our current view is that SSL/TLS is a good choice for AxCrypt. Better the devil you know, than the one you don’t, is part of it. We’re aware of various issues with SSL/TLS but we believe they are not generally relevant to our situation.
We currently have no plan to use SRP or any other mechanism, for establishing a secure connection between client and server.
Of course, this may change, but that’s the current viewpoint.
Hello,
There is a password, it’s the password you use to sign in to AxCrypt with. But, that’s your personal secret password you should never share with anyone.
To share an encrypted file, select the ‘key sharing’ option, and enter the recipients AxCrypt ID (email address). This will cause a shared file key to be embedded into the file. You can then send the file to the recipient by whatever means.
When the recipient signs in to AxCrypt with his/her own password he/she will be able to open it.
See videos at https://forum.axcrypt.net/ .
Hello Janae,
Please send screen shots of the situation, along with a detailed description of what happened, and what does not happen now to support att axcrypt dott net.
-
AuthorPosts