SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
Cuchulainn
Posts: 60518
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Crypto problem

March 10th, 2014, 8:41 am

At nano level? Micro text?
http://www.datasimfinancial.com
http://www.datasim.nl

Approach your problem from the right end and begin with the answers. Then one day, perhaps you will find the final question..
R. van Gulik
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Crypto problem

March 10th, 2014, 12:50 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnAt nano level? Micro text?I don't understand this question. ?I'm talking about storing and retrieving bytes on a computer. You can think of that data as a high dimensional object; a set of byte vectors, each byte vector representing a point in space. The geometric struture is just an interpretation of the bytes/data to make it easier to talk about things like "low-dimensional projections".In the plot you see two complicated 3d objects. The projections on the side planes of that object give the letters GEB. For crypto storage the 3d object and the projections would be very high dimensional object, the projection very non-linear functions, and the result of those projections a noisy sets of bits which ony the secret communicators know the meaning of (it would encrypted messages). The main point is that you write different data (a 3d object) than you read (a 2d projection) The "B" projection on the floor is very interesting! It seems to depend on both 3D object, but any of them will do even though the 3D objects look very different. Two different objects map to the same B in the floor projection but to different letters in other projections.Sounds like a variant of the [l=digital sundial] or maybe a way to see the Statue of Liberty from random pictures in New York City. The questions are: 1. To write N bits into the data store, how many bits must be written or changed in the data store?2. To read those N bits from the data store, without revealing which N bits one wants, how many bits must be read from the data store?
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Crypto problem

March 10th, 2014, 7:17 pm

QuoteOriginally posted by: outrunThose two questions indeed determine the probability that one person it communicating with someone else. Maybe it's a good idea to express it as probabilities that A communicates with B? Maybe also start with storing a single bit? Start out simple with Venn diagrams and combinatoric stuff.I was still thinking about the difference between communicating bytes and affecting bytes. Eg suppose I send one 1 byte to the storage and that changes a parameter of a decoding algoritm, then that single byte will affect all byte being read.I also ran into this article. It's about communicating on a noisy channel without retransmission. You stop reading the noisy stream when you have enough certainly that you can decode. Something like this can be used. You can look at "deliberate wrong random obfuscating read operations" as a highly noisy channel.The noisy channel analogy is somewhat applicable except with regard to statistics over time. In a world of IID noise, the hidden signal (i.e., who is messaging whom) will become clear.The reader does NOT want to make random obfuscating read operations because that would eventually lead to their unmasking when the watcher notices that the reader is most often tapping bits written by a particular writer. If the reader consistently acts to retrieve bits written/affected by a constant set of N writers (e.g., reads the same newspaper ever day), the watcher can never decide which writer the reader is in communications with.
 
User avatar
hamster
Posts: 216
Joined: October 12th, 2008, 3:51 pm

Crypto problem

March 10th, 2014, 10:00 pm

you might add the remailer mixmaster to your efforthttp://www.debian-administration.org/articles/ ... forge.net/
 
User avatar
hamster
Posts: 216
Joined: October 12th, 2008, 3:51 pm

Crypto problem

March 11th, 2014, 6:19 pm

QuoteOriginally posted by: outrunlol, there is a joke in the Debian manual. It say's "ioerror@nsa". Ioerror is the twitter handle of Jacob Appelbaum :-) of course a remailer is not the 100% solution. cant be bcoz there is none.you can compare the mixer (mix type II) to an onion router - both pack and unpack your (splitted) message like an onion- the tor network uses directory servers to manage all nodes. if someone hacks a directory server all communications can be traced (and manipulated). - mix type II dont uses a directory server. however your own setup can be hacked.- tor transmit the message as fast as it can, i.e. a unfriendly spy have the possibility to listen within a limited time frame- mix type II postpones on purpose, e.g. some spy programs wouldnt wait or might interpret it as new or abrupted transmission- you can design your mix type II net over multiple jurisdictions. if you messed it up you can still hope that multinational law enforcement is slow.i think the high latency trick is the important part (just do the opposite what a hft shop would do)
 
User avatar
hamster
Posts: 216
Joined: October 12th, 2008, 3:51 pm

Crypto problem

March 11th, 2014, 6:28 pm

QuoteOriginally posted by: outrunthis "Ostrovsky's Anonymous Broadcast via XOR-Trees" is smart. It's a method for hiding a message sender in a network. Not exactly the same problem but it has smart elements.* The first idea is to have N senders, 1 real one and N-1 fake ones that send random data. The receiver collects N messages, tries to decode them, and then will be able to identify the real message. The drawback is that it has a factor N communication overhead.* The second idea is to connect N senders in a ring, passing along messages. Each one XORs the message with a uniquely seeded pseudorandom stream. The receiver know the seeds and will be able to un-XOR all the random streams off the message. The drawback of this is that it's computationally expensive method. The receiver will need to internally replicate all the XOR streams.* The 3rd method lets each sender decode it's incoming message before re-encoding it with a different stream and forward it. All incoming and outgoing messages will be completely uncorrelated (unless you know the seeds)the last one looks like a mixer.i like the expensive first idea. the best place to hide is in a crowd. however i would generate pure pseudorandom fake data. be prepared for the future. today's encryption will not be a big deal tomorrow. for example if your data is a picture of mountain, the fake data should be pictures of other moutains too. if someone cracks your setup it shouldnt be possible to tell what is real.
Last edited by hamster on March 10th, 2014, 11:00 pm, edited 1 time in total.
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On