Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas about transforming SMS Secure into a sort of “TOR SMS” #1

Open
bernardoraymondo opened this issue Nov 8, 2015 · 0 comments

Comments

@bernardoraymondo
Copy link
Owner

Object : Ideas about transforming SMS Secure into a sort of “TOR SMS”

I suggest that SMS Secure has the potential to become (one of) the ultimate tool(s) for private communication

I am sorry if I am boring you with something well known not to be a good idea, I am not fully aware of that. And excuse me for my poor English

I assume that the following premises are true:
P1 : the government is monitoring all the Internet and SMS streams
P2 : the government is controlling all the centralized structures of the Internet
P3 : everyone I don’t personally know is a government agent
P3w : a weakened P3 : friends of my friends are probably not government agents
P4 : anonymity has a price, in comfort, in speed, in user friendliness

(Hereafter a “friend” is someone in my address book, and a “TOR SMS” user)

If we list our legitimate purposes about private communication:

1°) First : the government does not know what I say :

That is what SMS Secure is built for

2°) the government does not know who I am speaking to:

It can be achieved by using a circuit of 3 intermediate nodes, it is the TOR principle:

If me Alan (A) want to send an SMS to Eric (E), I use public keys (SMS Secure already manages it) to encapsulate several times my SMS to deliver it to E, through 3 intermediate hops :

A=> (B=>C=>D) ) =>E

B, C, D have to be friends;

2.1: first problem : unlike on the Internet, a phone number is linked to a person, it can’t be peaked so easily, and I have not enough phone numbers in my address book to use it as intermediate nodes.

And assuming P2, we can not build public keys severs.

We can benefit from P3w; but if my friends give me the numbers of their friends, it would be a breach in their privacy:

I suggest that I would broadcast the numbers and the public keys of my address book, not directly, but via a circuit A=> (B=>C=>D) ) =>E, without giving the information that I am A; so E would receive special sms with numbers and public keys, knowing it belongs to a friend of a friend, but without knowing who precisely.

The process could be that several times a day I peak an E in my address book, and a BCD circuit in my address book, and I send to E a random part of my adress book (numbers + associated keys) : this process ensures that my friends will have more and more numbers with public keys to peak as nodes, and I will have more and more of it.

2.2 second problem : assuming P1, the government would immediately see the successive hops and understanding that Alan is talking to Eric

If we accept P4, it could be solved by not processing the next hop of a circuit immediately, but at regular periods: so a node would send several encrypted sms at each end of period to the next nodes of the circuits: the more the nodes in the system, the shorter the period could be. In TOR the circuits are shadowed by the high entropy of the Internet.

3°) the government does not know who I know

It can be achieved by managing inside “TOR SMS” a secret address book, and encapsulating the key exchanging process into a circuit. So if I send to a person I know via a circuit my number an my public key, the government would not be able to know that the exchange has been done; of course 2.2 has to be respected.

4°) the government does not even know that I speak

It can be processed using the Bluetooth connection each time it is possible for the first hop (the same principle as FireChat…)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant