ssm - a Secure Storage Method

see also

The ssm (secure storage method), while using encryption methods such as the gnupg (which, as any known other, is finally breakable by our big brothers), is not only about securing the communication between peers (and although moving the data) but is mainly about providing a storage mechanism in a cluster of units (cloud computing) for data able to be stored more securely with more of its movement and doing so as much as such security is desired (in a price, which is proportional to the number of movements, of slower fetching due to a longer decryption ).

It does so by simply combining the movement of data between some units (so that it is harder to locate it) while re-encrypting the data before each such move (so that is is harder to decode it).

Such data is moved between dip (data ip) units storing the re-encrypted data, where the dip units are not mixed with another group of units: the kip (key ip), in each of which some keyring are kept and where both groups (the dip and kip) are not mixed with another third group: the sip (server ip) providing the services in relation to such data.

In Dip shall be done
when As desired (use cron from kip) in writing. As required from sip in reading.
The access Writing only from kip. Reading only from sip.
what in writing each data's move between dip is only after first being Re-encrypted in kip.
where The data in its deepest encrypted state is only in ONE dip known to sip for reading.
The keys are never on dip.

| kip |Always per each reading |
| |re-decrypting while |
| sip |serving both reading and writing for the user |

If id==x, then the data is ready for be decrypted by the private key of the user and as such is sent to the sip, otherwise the id is of the key able to decrypt the data but only in the corresponding kip.

If ip ==y, then the key shall be processed in the current ip (mostly decrypting the data and than, depend on the id, sending the data to sip when id==x, or to kip corresponding to the new id), otherwise, when ip!=y, the data shall be moved to be processed to the ip, where such ip are only kip.

In each re-encryption at the additional 4 byte being expanded at the end of the data sits the id of the last key which encrypted it (unless id==x).

In each of the kip and in at-least one of the sip units, one table of id(key) -> encrypted(ip(process_to_decrypt_with_the_key)) is used, but such table is not necessarily identical, where x or y are kept secret and even they can be changed between some hubs of such units.

only last dip is stored in sip <—moment

Add a New Comment

see also
By comcomistcomcomist, on 08 Jul 2012 17:37 history Tags:


~~Page's End!~~ Ignore ads by installing adblockplus.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License