BTW, another thing to consider is the encryption algorhytm implementation. Anyone can claim (and believe) that they created an AES-compliant encryption program, but it doesn't mean they really have the skill or knowledge or experience.
It looks like the creator of FreeOTFE is fairly well known on sci.crypt and similar forums, also it's an open source software IIRC.
As for ccrryyppttoo, FileBarricader etc. - I don't have a slightest idea about the software itself or its authors.
I use eWallet, but I would not place RC4 among AES, Serpent, Blowfish. RC4 has been broken, but at 40-bit. Practically speaking, it's good enough for casual use. But I feel better using an algorithm that hasn't been broken, even if it's at a lower bit.
Actually the 'broken' part refers to a flaw that eWallet doesn't suffer from. As long as you select a good password 256 bit RC4 encryption would take something in the area of 20,000 years to hack by brute force.
And the difference between 40 bit and 256 bit is astronomical since it is an exponential increase in security. I agree that there are stronger means of encryption but quite frankly, unless you are under the serious threat of a major government attempting to hack your wallet, it is simply overkill.
And yes, in the end it all comes down to a good password.
Actually the 'broken' part refers to a flaw that eWallet doesn't suffer from. As long as you select a good password 256 bit RC4 encryption would take something in the area of 20,000 years to hack by brute force.
And the difference between 40 bit and 256 bit is astronomical since it is an exponential increase in security. I agree that there are stronger means of encryption but quite frankly, unless you are under the serious threat of a major government attempting to hack your wallet, it is simply overkill.
And yes, in the end it all comes down to a good password.
While it may provide a good security today, think of someone obtaining your wallet file, e.g. on a lost backup CD, & trying to break it with computers and tools available 10-15 years from now. Some information (SSN, some bank accounts, retirement accounts) is still going to be relevant. Of course the chances are very slim but... it's better to be paranoid than sorry. I would, at any given point, use only the strongest algorhytm currently available. ( IIRC that older version of eWallet used something like RC64)
Now in my case switching from eWallet to KeePass was also a features vs. memory use choice.
It's only as strong as the weakest link - this may be your password (normally it's the case), the algorhytm, the weakness in code, etc.
A two character password makes using any encryption useless.
A strong password (that I define as 10+ upper and lower case letters and numbers not containing any dictionary words) makes it hard to brute force, but if ten years from now they have tools and know-how allowing one to break, say, RC40 without being a scientist, now your password becomes irrelevant.
Bottom line, one needs to be using the strongest password one can live with, the strongest algorhytm available, and the program one can trust to be free of backdoors and holes. Can't be safe unless all three conditions are reasonably met.
It's only as strong as the weakest link - this may be your password (normally it's the case)...
A strong password (that I define as 10+ upper and lower case letters and numbers not containing any dictionary words) makes it hard to brute force....
Agree :approve: ... and don't forget that you may use figures like @ £ ¤ or Alt characters like Å (Alt143), Ñ which might be remembered as 1965 (Alt165)
Actually the 'broken' part refers to a flaw that eWallet doesn't suffer from. As long as you select a good password 256 bit RC4 encryption would take something in the area of 20,000 years to hack by brute force.
And the difference between 40 bit and 256 bit is astronomical since it is an exponential increase in security. I agree that there are stronger means of encryption but quite frankly, unless you are under the serious threat of a major government attempting to hack your wallet, it is simply overkill.
And yes, in the end it all comes down to a good password.
Marc Tassin
Ilium Software
--------------------
My post was quite clear thank you. RC4 was broken at 40-bit.
And "overkill" is relative. But when it comes to my security, overkill is always better. Like I said, I use eWallet, but I would not consider it the most secure option. Don't know why eWallet doesn't use a more standard encryption algorithm like AES - the government standard. Or at least another algorithm that hasn't been broken - even if it was at a lower bitrate. It can't really increase processing overhead by that much more.
Agree :approve: ... and don't forget that you may use figures like @ £ ¤ or Alt characters like Å (Alt143), Ñ which might be remembered as 1965 (Alt165)
.
Right, but I am trying to come up with passwords that sound like pseudo-words and are easier to remember - e.g. SopUrtiNougA223. I just have to repeat it 4-5 times and the word sticks in my mind. Of course it helps that I only have to remember 2-3 of them at the time, the rest are in my KeePass database.
Whatever works for you. This will be impossible for a random thief to deduct, but purely theoretically may be easier for someone close to you (although this is still a wild stretch, imho). The bottom line is, it's long, random (for anyone not close to you) and hard to guess (even for somebody close to you).
It's of course just an example ment to demonstrate a nmemo technique for creating good, valid passwords for systems using the password as a salt, say PGP or the like
Send me all your files and I will encrypt them for you!!
This is a great idea! It is like FreeCreditReport.com etc. You could offer free basic encryption services and then charge a minimal charge for decryption. If they want beyond the basic encryption services you could charge for things like levels of identity protection. All this can be explained in a very long disclosure statement. The possibilities…
Follow Us
RSS Feed
Follow on Twitter
Facebook
YouTube
