Wenn die DB verschlüsselt ist, muss erstmal die Applikation laufen, dass auf die Daten zugegriffen werden kann. Das ist schon recht aufwendig und selbst dann werden wohl auch nicht alle Nachrichten im Arbeitsspeicher liegen. Selbst wenn der Schlüssel für die DB irgendwo daneben im Klartext liegen würde, ist das für den Angreifer aufwendiger. Ein Angriff müsste schon speziell auf das Problem zugeschnitten sein.
Der Schlüssel im Klartext daneben - nicht ernsthaft? So eine Implementierung würde ich ja mal kategorisch ablehnen, einfach weil sie keinen Sicherheitsvorteil bringt oder - im schlimmsten Fall - ein falsches Gefühl für Sicherheit dem Nutzer gegenüber.
Klar muss erst mal eine Anwendung geschrieben werden, die das Format dann auch parst und den Schlüssel am richtigen Ort findet, aber das ist nicht sicherheitsrelevant. Dass wiederspricht schon dem altbewährten Kerkhoffs'schen Prinzip, denn bei der Herangehensweise wäre ja der Algorithmus das "geheime", den der Malware-Programmierer nicht kennt (bzw. nicht implementiert hat).
Bei Android würde ich dir da allerdings noch zustimmen, da dort die Anwendungen gesandboxed sind und somit eine Anwendung nicht auf den Speicher (und den Schlüssel) der anderen Anwendung zugreifen kann. Da bei Windows jedoch jede Anwendung auch den danebenliegenden Schlüssel einfach abgreifen kann, würde solch ein "Schutz" keinen Sinn machen.
Eine Verschlüsselung mit einem Password macht da schon mehr Sinn. Zwar könnte eine laufende Anwendung die Daten auch abgreifen, aber zumindest vor Diebstahl oder bei manchen unterschiedlichen Nutzungszenarien (z.B.: Passwort wird nur selten eingegeben und eventuell vorhandenen Malware wurde vor der nächsten Passworteingabe schon entdeckt) schützt dies dann schon sehr gut. Aus den gleichem Grund verwendet man ja auch Passwort-Manager und speichert seine Passwörter nicht unverschlüsselt auf der Festplatte (im Browser) ab.
