ChrisCN wrote:Can someone use the stored string to open CN without knowing the password?

Ok, the following is my understanding - I am not a Cryptographer, so while I believe the following to be accurate, I cannot absolutely guarantee it is. I am sure that Alex will chime in here as well.

If that is an AES encrypted string as I assume it is, I don't believe so. If the user has selected that option and closed CN, when you attempt to open it again, you are prompted for the password. The only way you can get past this is to provide the correct password. That means decoding that string (you can't enter the string directly into the password box, and the string is already in the cintanotes.settings file, so it isn't a case of being able to enter it into the file to magically unlock the database either).

So, is it possible to decrypt an AES encrypted string? Theoretically, I suppose it is. In practice, I don't believe it is. There are only three ways I can think of to attack it.

1. A colossal mistake in the implementation of the library in CN. I am assuming Alex has implemented an existing AES library rather than tried to make his own - the first thing a Cryptographer will tell you is to not try to implement an algorithm yourself if you are not a Cryptographer as it is extremely easy to screw something up and leave the encryption wide open to attack. Instead, they suggest implementing a library that has been designed by someone who knows what they are doing and has been subject to intense scrutiny and audit. While a mistake in CN's code which adds support for the library is possible, we would never know if that was the case until someone was able to prove it (by a successful attack).

2. The AES algorithm was suddenly - and completely - broken. AES has been subject to intense efforts by Cryptographers and other groups to break it in the years since it was introduced, and no one has publicly succeeded in doing so (if anyone has, they have not announced it - I think it is fairly unlikely it has been, the Snowden leaks have given no indication that even the NSA has been able to do this and if they can't, no one else would have the resources to do it either). If AES was broken, we would have far larger problems than CN - AES is used absolutely everywhere and the damage caused by a complete break of the algorithm would be enormous. There have been successful attacks that can reduce the number of rounds required to decrypt a string encrypted with AES in some circumstances, but the amount of effort required is still in the realm of 'the heat death of the universe will occur first' (ie billions of years).

3. If the attacker knew the way the algorithm was implemented - by checking the code for example - they may be able to attempt a brute force attack on the string (assuming they have the string from the cintanotes.settings file). If the encryption is implemented with a random salt, than this stands no chance of succeeding. If the user password is i. small enough, and ii. is a common dictionary word, then theoretically, a brute force attack may stand a chance of succeeding. With a long enough password, and using no words in the dictionary, a brute force attack will not succeed unless there is a quantum shift in computing power (even brute forcing a short 8 character password with some special characters and no words in the dictionary would take billions of years with the fastest computers currently existing). It is also open to CN to have implemented an extra measure against brute force attacks, similar to what KeePass has done. That is, added some things to slow down the number of password guesses that can be made per second, putting the likelihood of a successful attack even further beyond reach.

With all that said - an attacker would have to be stupid and/or desperate to try and break that string. The single best way for someone to get into your CN database is to get a keylogger on your system and intercept your password as you type it into CN. After that, all they need is a copy of the database - and if they managed to get a keylogger onto your system, why not a trojan that uploads the database to another location as well? Some malware in fact combines these capabilities. Of course, if the attacker knew you, they could obtain a copy of the database and try various password guesses (your date of birth, your dog's name, your name, the usual suspect passwords such as '123' and 'password' etc). If they succeed in this way, it's your own fault for choosing an obvious password!

ChrisCN wrote:It also doesn't help to remove it later because Dropbox is keeping all old versions of a file!?

This would only become an issue if they could decrypt that password string, which as I have posted above, I don't believe is possible.

ChrisCN wrote:Regarding 'saving the password' I wonder if this is a security risk when using Dropbox to store and sync CN data and settings (this is how I use it for years).

It could be a security risk (see below)I'd recommend to only store the .db file in the Dropbox folder.

Can someone use the stored string to open CN without knowing the password?

CN stores only a hash of the password, taken 500 or so times, encrypted with Blowfish (which is as good as AES). After it loads it, it applies hashing several hundred more times to get the real password hash that can unlock the database (the passphrase that the user enters is not used for that, it serves only for calculating the hash that becomes the real password).

So it will certainly take a very determined hacker to crack this. Quite a bit of reverse-engineering CN with a gooddebugger will be required. Certainly not something for non-specialists. But still possible.

And I don't exclude the possibility that if CN becomes very popular, determined hackers could produce tools for cracking CN databases, which would work using the stored passwordand which could be downloaded and used by anyone.

So if you're concerned about this, it's better to use the "don't remember password" option (and change passwordafter that).

usbpoweredfridge wrote:Ok, the following is my understanding - I am not a Cryptographer, so while I believe the following to be accurate, I cannot absolutely guarantee it is. I am sure that Alex will chime in here as well.

Great analysis, Chris! You're correct on almost every point. We use Blowfish instead of AES, but this is of little difference on a data set of such small size.

Since the beginning I use CintaNotes' portable version stored in Dropbox.So I am not only syncing the database but also the settings and even the program executable.Maximum portability

This scenario leaves two options 1) I don't use the remember password feature. (Must give it a try and see how annoying this will be) 2) I only store the db file in Dropbox - which also means I don't backup my settings to Dropbox (or any other cloud service).

Maybe it would be a nice option to store the password hash on a different location where it can be excluded from any cloud sync and backups without effecting the settings.

CintaNotes Developer wrote:Great analysis, Chris! You're correct on almost every point. We use Blowfish instead of AES, but this is of little difference on a data set of such small size.

Ah, the venerable Blowfish A reasonable choice I think - it is slightly older than AES, but a very solid algorithm that was designed by someone with a good reputation as a Cryptographer and which has had quite a bit of attention paid to it in an attempt to find holes in it. I haven't heard any reports of it being broken, but I checked Wikipedia just to be sure (if it had been, it would likely have been mentioned there). The only issues Wikipedia listed under 'weaknesses' for Blowfish are that it is known to be susceptible to attacks on reflectively weak keys, and that the FAQ for GnuPG recommends that Blowfish should not be used to encrypt files that are larger than 4GB.

Just to get my head around it, the encryption for both the database and the password are Blowfish, or the database is AES-256 (which you mentioned in the Beta 1 thread) and the password is Blowfish?

ChrisCN wrote:Maybe it would be a nice option to store the password hash on a different location where it can be excluded from any cloud sync and backups without effecting the settings.

Chris, i agree and suggest to make this mandatory. It should not be an option. The password (or its hash) should never leave the local harddisk. It would be better to store the pw-hash in a separate file. To avoid automatic syncing with dropbox, a default location should be chosen, which is outside the scope of dropbox syncing.

ChrisCN wrote:1) I don't use the remember password feature. (Must give it a try and see how annoying this will be)

Ok, I'm anxious to hear the results of this test

ChrisCN wrote:Maybe it would be a nice option to store the password hash on a different location where it can be excluded from any cloud sync and backups without effecting the settings.

There's a reason I don't recommend storing the settings file in Dropbox. It contains many PC-dependent things, like paths to all open notebooks, and window locations (which depend on the workstation monitor settings). So I don't think we'll be adding an option to store the password elsewhere, sorry)

usbpoweredfridge wrote:Just to get my head around it, the encryption for both the database and the password are Blowfish, or the database is AES-256 (which you mentioned in the Beta 1 thread) and the password is Blowfish?

Only the password is Blowfish, for encrypting the DB we use SQLCipher, which in its turn uses AES-256.

ChrisCN wrote:Maybe it would be a nice option to store the password hash on a different location where it can be excluded from any cloud sync and backups without effecting the settings.

There's a reason I don't recommend storing the settings file in Dropbox. It contains many PC-dependent things, like paths to all open notebooks, and window locations (which depend on the workstation monitor settings). So I don't think we'll be adding an option to store the password elsewhere, sorry)

I don't want to talk you into implementing this options (or maybe just a little bit ) BUT I never thought it would be a problem to use the portable version "portable" I store the portable version on dropbox instead of an USB stick - this way I get a backup of the settings AND can use it from everywhere (including my familiar settings). I can't see this is doing any harm!?

That's how I use CN as well. The portable version of CN is in a Dropbox folder (except for the backups) and all notebooks are in Dropbox also. The Dropbox folder is in the same location on all machines, so the paths to the notebooks are the same. I have the same settings on all machines and if I update CN on one computer, all others use the same version. Works fine for me.

I think what Alex is trying to say is that portable CN is not absolutely 100% portable (ie it uses absolute paths instead of relative paths, and your CN window position will quite possibly be in a different spot on each system you use it on due to Windows display settings). You can obviously use CN in this way (ie by syncing the settings file as well), he just doesn't recommend it.

CintaNotes Developer wrote:Only the password is Blowfish, for encrypting the DB we use SQLCipher, which in its turn uses AES-256.

ChrisCN wrote:I don't want to talk you into implementing this options (or maybe just a little bit ) BUT I never thought it would be a problem to use the portable version "portable" I store the portable version on dropbox instead of an USB stick - this way I get a backup of the settings AND can use it from everywhere (including my familiar settings). I can't see this is doing any harm!?

No harm whatsoever. But by doing this you accept the fact that workstation-sensitive settings (such as window locations) may collide with each other.

Also CintaNotes is smart enough to use relative paths for notebooks located on the level of cintanotes.exe or below, but it can't do that for notebook located elsewhere.

That's all, basically. And btw if we choose so store password somewhere outside, we'll be losing this portability.

gunars wrote:That's how I use CN as well. The portable version of CN is in a Dropbox folder (except for the backups) and all notebooks are in Dropbox also. The Dropbox folder is in the same location on all machines, so the paths to the notebooks are the same. I have the same settings on all machines and if I update CN on one computer, all others use the same version. Works fine for me.

Thanks for stepping in , Gunars. Yes, this way is not recommended only because of possible settings conflicts, that's all. If on each PC you have same monitor settings and folders, there should be no problem.

usbpoweredfridge wrote:I think what Alex is trying to say is that portable CN is not absolutely 100% portable (ie it uses absolute paths instead of relative paths, and your CN window position will quite possibly be in a different spot on each system you use it on due to Windows display settings). You can obviously use CN in this way (ie by syncing the settings file as well), he just doesn't recommend it.