Tips on conceiving safe software messaging platform I have a personal project in mind in which I plan to use cryptography in order to let the users be confident in the fact that, even if all data get's stolen, it would be virtually impossible to crack in the next few decades.

I would like some advice on the way I planned it until now:

All data resides in two key/value stores:

Store 1 - contains messages:


key   : msg_id (numerical)  
value : AES encrypted message with random key K1.


Store 2 - links users to messages:


key   : hash H1 of (user identification + password + X)
value : AES encrypted data containing the msg_id and key K1, encrypted with key K2 (identification + password + salt/padding)


( X increments from 1 to N, per message linked to user. I use this to create more noise, should there be an attack, and to differentiate the hash H1 with key K2).

Without any regard to the way it should work (which is quite specific): is the data contained in the two stores safe even if an attacker knows their architecture and has access to the application's source code ? They may know some user id's, but not their password.

BTW: I'm quite new to cryptography. I'm reading through the basic materials (applied cryptography by Bruce Schneier, for one), so please be indulgent.
First, as a bit of general advice: Designing a secure cryptographic system is hard. Experts with decades of experience still make mistakes. Depending on your intended audience, you may be better served by looking for an established system that meets your needs rather than trying to design an implement something from scratch.

To answer your specific question above, I would suggest that the keys of store 2 are one weak point. With a list of these keys, and one or more user IDs known, it's straightforward to implement a dictionary attack to try and discover the associated passwords. (X does nothing to help protect the passwords, because it is not random.)

Passwords are notoriously a weak point of most systems in use today, thus you might contend that this is unavoidable, but you should still strive to avoid making it easy to do an offline dictionary attack.