As you remember, the strength of the crypto system depends largely on the complexity of the password.

Let me remind you how the length of a password corresponds to cracking time:
Lets assume that a password consists of lower and upper case letters, digits and special symbols. That makes an «alphabet» be about 80 symbols. The length of a password that is easy to remember is up to 6-8 symbols. There are 80^6 to 80^8 potential passwords. Considering modern computing hardware it is quite possible to brute force such passwords, depending on a motivation to find it, of course. Generally, a password shorter than 6 symbols is not secure at all. The real problem for a cracker starts with a password longer than 10-12 symbols.
But a user is going to face a problem as well. It is hard to remember. Hard to remember passwords tend to become weak. Well, not the password itself, but the way a user manages them. He may write it down, use the same password for several logins or compose the password in a weak way.

If you need a good password that you can remember, take a thick dictionary that you cannot lift by one hand and select 6 words randomly, I mean randomly - not the words you like or the words that make a meaningful sentence. This is going to be safe enough. Google «Diceware» to learn more.

We have a better solution

We designed a feature that eliminates the need to memorize such a long password. SenseMail can use a certificate to encrypt a message. A certificate is a 256-bit sequence of random data. To brute force that key an adversary need to try up to 2^256 passwords, that will take him a bit more that an eternity.

There are some issues with that approach.
First, you need to generate a random certificate. Where to get random data from? We made a tool to generate such data. You tap a screen and each tap gives us 8 bits of random data.
One may argue that these bits are truly random. Yes, we agree to a certain extent, truly random data can be obtained from your pocket nuclear reactor… you don’t have one? So, lets use other sources that are available to you. These sources need to be physical so it is impossible to repeat the same sequence. We cannot use algorithms to produce the certificate. So, we measure time between your taps. Very precisely, up to nanoseconds, so even if you think that you tap the screen with the same interval, it is not. We are aware that this type of input could be tampered with, so we print the raw data you get and if you see something strange, for example the same numbers being produced, you know that you cannot trust the resulting key.
You need to tap at least 32 times, although you may tap just twice (not a good idea, don't do so) or tap 500 times. The more the better, but don't be paranoid – 32 times is good, 64 is better, 256 times would definitely be an overkill.
After that we use a slow key derivation procedure to obtain a final certificate. Saying slow I mean that we use 444,440 rounds of PBKDF2-SHA512. That makes it easier to brute-force the resulting key than to analyze and try to find vulnerabilities in your tapping. Nobody with a common sense will attempt to brute-force a 256-bit AES key... There are plenty of other ways to find a password. Some of them you may not like at all, including the last resort – thermorec...hmm... cryptanalysis.

So, we have got a certificate.

Here appears the second issue.

We need to send this certificate to our recipient. This is a real problem… We tried to help you and created a tool that converts the certificate to a QR-code that can be scanned by the other device. Here you are!
If you recipient is not in person near you, this is going to be harder. There’s a printable representation of a key that you can read by the phone, for example. But don’t ever send that code by SMS or using an email or a messenger since it is easy to recover your message. The best option is to meet in person, anyway.

The last but not the least issue is how to keep a certificate.
You should remember, that the main purpose of a certificate is to keep your messages secure when they leave your device. A certificate is kept on a device, protected by a password you set. If your device was captured, a certificate could be recovered, depending on the password that protects it. This password is weaker than a certificate, but when you've sent a message an adversary have no access to your storage, so, the protection is not compromised by a weaker password. Luckily, you can (and should) have a separate certificate for every of your recipients, so an adversary needs to recover many passwords.
Actually, your certificate is double-protected — first, there's a password you type to launch the app, second - there's a password used to encrypt a certificate.

Real-time boring demo is here: