the SDSP - Secure Data Storage Prootocol - (aka SDP)
logo.jpg
+ More&Related...

Thanks for your interest. This site (except of this page) is closed only for the developers. What we find propriate to pubilc you can find on http://comcomist.wikidot.com/

On this site: search the site

Peer Owners Stations - 09 Jul 2012 12:22

https://Github.com/Comcomist/Comcom-Platforms - 09 Jul 2012 12:22

Registrationusecase - 09 Jul 2012 12:22

Use cases - 09 Jul 2012 12:22

Auth - 09 Jul 2012 12:22

Comcom Platforms - 09 Jul 2012 12:22

Yncyrydybyl - 09 Jul 2012 12:22

Making Flexibility Of C And V In The T* D =C* V. Txt - 09 Jul 2012 12:22

Sorting X In T - 09 Jul 2012 12:22

Comcom Tech - 09 Jul 2012 12:22

the SDSP - Secure Data Storage Prootocol - (aka SDP) - 09 Jul 2012 12:22

Comcomism Tri A4 N0 - 09 Jul 2012 12:22

Hi - 09 Jul 2012 12:22

How To Edit Pages - Quickstart - 09 Jul 2012 12:22

__ Secure Data Storage - Way?__
Both freedoms: of association (with your contacts) and of speech (in your communications with your contacts) CANNOT (be considered as free for you) and SHOULD NOT (be considered existing in any free society), if they are able to be constantly monitored.

Both freedoms, of association and speech, could only be established when only what you publish could be monitored as it is attributed to you as being your speech (and the same goes for yourself belonging to group only when you choose to show it, e.g. in demonstration), but only as it is completely distinguished from your associations with your friends and messaging to your contacts. Hence if and when our contacts and messaging are constantly able to be monitored, (then as such they cannot distinguished from the speech and association and so) we do not live in a free sociality.

Assuming that (sooner or later) any communication is able to be monitored, here (and based on the use of existing "normal and secure" data communication) we try to develop data storage technique which is affordable for most of the users. The issue here is the storage not the communication.

in short:
1) re-encryption (optionally with noise cleanable by header)2) replacing of holders of key (optionally of data) after each event of read 3) complete separation between keys and data 4) data can be opened only by both: client and system (with no supper role)
optional:
5) the owner of data is not its holder as the holders of data are organized in an independent (and comcomized?) group and 6) the size of my data equals the size of the data (optionally chunked) i hold for my friends. 7) the holding is in my-pc/temporary-holder/my-node. my-node is in the Internet for cases of those government which would not allow having data being encoded in pc.

For the obligatory case (1,2,3,4): the server is cloud of keys surrounded by proxies and the user is its data holder:
on write:

  1. user encrypt <k1> msg=enc(msg) .
  2. strong shaking hands.
  3. user get from server an encrypted <k2> ticket, which latter will be used as a encrypted header consisting of id(ip) and id (key) - at this point the decrypted header is invalid.
  4. user encrypt <k3> the header so that enc_header =enc(header).
  5. user send msg to server.
  6. server encrypt <k4> enc_msg=(msg), after this ,the header become valid, hence the id(ip) points to the ip in which id specify the key ( the key being k4) to decrypt the data.
  7. server send enc_msg to user
  8. end of shake hands.
  9. user encrypt <k5> enc_data=enc(enc_msg,enc_header ) and store it.

legend: m==message, t==ticket==header,the keys <1,<2,<3,<4,<5
on write 1: |m|<1|
on write 3: |t|<2|
on write 4: |t|2|<3|
on write 6: |m|1|<4|
on write 9: |m|1|4|, |t|2|3|<5|

on read:

  1. user decrypt <k5> enc_data - the msg is still encrypted by the key in the server.
  2. user decrypt <k3> header - the header is still encrypted by the key in the server.
  3. strong shaking hands
  4. user send to server both (decrypted header,decrypted msg)
  5. server decrypt <k2> header=ticket.
  6. as defined in header - said ip decrypt <k4> msg by said key.
  7. said key moves to another ip - invalidating the id(ip) and id(key), (thereby the new valid t, hereby t2, will be sent to user, for be encrypted <5> by the user, for any reading after the current, all tat for implementing the "hit and run" method).
  8. server send to user data=the msg, which is still encrypted by <k1> and a new t, the t2 for latter use. This way the system can be alarmed on wrong use of the t.
  9. end of shake hands.
  10. user decrypt <k1> the msg.

notes: In the header, other 2 pairs of elements could added
1. [ id(offset) , id(size) ] so that the reset is dirt and 2. [id(crypto), id( parameter to crypto) so that different mechanism of encryption can be implemented. e.g. on www.garykessler.net/library/crypto.html#fig01

Secure%20data%20storage%20by%20the%20SDP.gif

see also tor-proxy
We are using the Sealed Data Protocol (the sdp) for the Comcomized Mailing Services, which is based on p2p communication and/or encrypted emailing between the users and

  • on 2 directories1 per user:
    • the their (having encrypted data of the peers of the user)2 and
    • the my (having encrypted data of the user) and
  • on 2 separated clouds:
    • the keys (storing only private keys able opening the data in the their directories and accessed only via tor-proxies) and
    • the sync (storing the their and my directories of the users).

For more see also my:comcomized-mailing-services and here

The sdp is defined so that the seal=(pid,kid), where

  1. pid is id of p being ip and kid is id of k being private key for which the msg is encrypted,
  2. the key (k) is always in another machine (p), other than where the encrypted msg is stored and
  3. the msg is attached with the seal, and as such, as being sealed, it is ready for being re-encrypted.
  • In the Peers mode(i.e. by the keys cloud operating from the their directories to the my directrory): the key is always in machine other than the one storing the encrypted data and
  • in both modes: the peer and the sync any role other than the data's owner (being the client) can never open (for view) the data and
    • when the data is sent it is sent encrypted and only the encrypted copies are stored, never the original (being flat)!!!
  • Closing the data: as the seal: is the pair of
    • A) id of the machine able to open it and
    • B) id of the private key,
  • as the seal is closed, after being double encrypted by both3
    • 1st client then
    • 2nd the tor-proxy,
  • and as the seal is attached together with the data into one block being the data block, (which is ready for being firstly or additionally encrypted), where the data block is
    • 1st being compressed (but only in the first closing) then
    • 2nd being encrypted then
    • 3rd being split into constant size4 elements,
    • 4th adding the seal in the last element, where all elements are
      • 5th sitting on a mounted-able drive, which is
      • 6th owned by the group including client-sdp-app and client-sync-app.

the ids: data id , user id

1.(of the user on one or more machines):

  • uid(user-id)->((ip,port),..),email,pass,..)

2.did (data id, being id of one block of data, which is 1st being compressed then 2nd being split into constant size elements 3rd sitting on a mounted-able drive, owned by client-sdp-app .):

  • 2.a.(united):
  • uid:did(data-id)->(ip,off,size,(n,..))
  • 2.b.(distributed):
  • uid:did(data-id)->((ip,off,size,n),..)
  • 2.note. ():
  • Per each uid, each ip on a port communicates with the client-sdp-app,
    • where the client knows the complete path to directory having the files named by n (name of the element) and
    • where each n is the name of the file being one element in block of data and all n ordered despondently to reading.

data id (is of number of elements , of offset and has the path)


the data block:

  1. Each msg (which is any data having ms-id=uid [user id] and ls-id=did [data id])additionally to its content has its seal and offset to its seal, where the offset is at its start and is either
    1. a positive offset to seal sitting at the end of the content of the msg, or
    2. a negative offset to the content of the msg sitting at the end of seal.
  2. The seal is data encrypted first by pub key of tor-proxy and then by the pub key of the client and it consists both
    1. id(ip), which is id of the ip in which the key can be used for decrypting the content of the msg and
    2. id(key), which is id of the key able to decrypt the content of the msg.
  3. On reading, while decryption and as the seal is decrypted by (en.wikipedia.org/wiki/Transport_Layer_Security) ssl/tls-Cipher suite on machine of the clients and as the content of the msg is decrypted by the key in the ip defined by seal, the seal is handled twice and from 2 ip
    1. once on the the ip having the msg , id(ip)=ssl(ip(seal)), array indexed by id to ip and
    2. once on the defined ip id(key)=ssl(key(seal)) , array indexed by id to key, hence on this machine by this key the content of the msg is decrypted (and until specific signal is found go to 1 for to re-decrypt the msg by its new seal).

todo

  1. to add type of ( based depended type of signals) ip/key
  2. to set restriction of listening machines + adding set of expectations with expiration dates
  3. encryption length, to add noise etc see the offset and base depended signals
  4. in updating while moving, since we use only id of ip and not ip and since we use only id of key and not key we can swap and modify while updating the movement in the array of ip and the key in the array of keys
  5. creating keys ???

for the manger of this project:

The development should be open and its manger should care for these points:

  1. when developed it should be licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 http://creativecommons.org/licenses/by-nc-sa/3.0/ so that
  2. those who contribute with such license could, when they want, to publish it or give it under another license, but then they first must cooperate on that and
  3. such cooperation we prefer to be based on comcomized unites.
  4. This way, only by giving services having the data of user, groups and/or keys is where we could have risk of a) the service does not use the exact published code? and b) the identity is falsified.
  • Since comcomism ltd is in the position to certificate the 4, we need for that to give service of bug report and report about missus and/or falsifying and this shall be part of the developing platform, but will be available for any working service and hence such platform is what the manger should realize.

have any question or other request? please try this:

Your email
Your request
Add a New Comment
or Sign in as Wikidot user
(will not be published)
- +
Help: wiki text quick reference

Hi

This site is a private one!! Its other pages are accessible only for its members.

The members are developers or admins in the other wikidot sites which are related to the ComComism movement.

From here we are creating activities which take place also out of the internet, meaning in the "real" world and so that, the sites manged by the admins in wikidot are those which would be used and/or referred-by such activities and so that the one out-there in the real world can always dynamically adjust the content in the site for the needs of the activity made by that one.

Such activities are from seminars in universities and until spreading stickers by us - the kids. We are also restoring here images and other stuff for the comcomizing use.

By pilepile, on 09 Jul 2012 12:22 history Tags:

comcomized-logo.png

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

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