in discussion Hidden / Per page discussions » List of Common Company (ComCom) groups - Join, create or host:
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
see also http://iswith.info/admin/-c-/page/a-secure-cloning-system
By comcomist, on 08 Jul 2012 17:37 history Tags:
~~Page's End!~~ Ignore ads by installing adblockplus.