Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kmfkewm

Pages: 1 ... 77 78 [79] 80 81 ... 249
1171
Security / Re: Theory: Blind markets
« on: May 10, 2013, 01:47 pm »
Encrypted keyword search allows a server to perform
a search over a set of encrypted documents on be-
half of a client without learning the contents of the
documents or the words being searched for. Design-
ing a practical system is challenging because the pri-
vacy constraint thwarts standard indexing and rank-
ing techniques. We present Mafdet, an encrypted
keyword search system we have implemented. Our
system makes the search practical even for large data
sets. We evaluated Mafdet’s performance on a set of
queries and a large collection of documents. In these
queries, Mafdet’s accuracy is within 6% of Google
Desktop, and the search time is on the order of sec-
onds for document sets as large as 2.6 GB.

...


Controlled searching. The server cannot learn
anything about the contents of documents, ex-
cept when the client performs a search.

Hidden queries. The client can search for a
set of documents containing a keyword without
revealing the keyword to the server.

Query isolation. From the query result, the
server learns nothing about the plain text other
than the set of documents that match the query
(and possibly the limited statistical information
used to perform ranking).

Update isolation. The server learns nothing
more from updates than it would if we main-
tained no additional metadata for the purpose of
performing searches.



1172
Security / Re: Theory: Blind markets
« on: May 10, 2013, 06:50 am »
Yeah, I'm starting to think that the only way this could work is if you got rid of the market admins altogether and used a decentralized database like the block chain. The "network" maintains it. As long as there is at least one node, the market continues to exist. Sellers submit listings which are encrypted but provide key words. Buyers discover listings by searching for key words. Transactions are p2p, so only the buyer and seller know that a particular transaction involves them (although anyone who downloads the database knows that a transaction exists, just like bitcoin transactions today).

You lose escrow and resolution, but that could be provided by third party services for a fee. In fact, that's what the role of "market admin" in today's markets could evolve into. Before engaging in a transaction, buyer and seller could agree to use a third party escrow/resolution service. They inform the service, which initiates the transaction, but the service doesn't know the content of the transaction (the product and price) until a dispute happens and it is revealed to them. In order to complete the transaction, both parties must sign it, or something along those lines. So a dispute happens when at least one party refuses to sign. At that point, the transaction details are revealed to the escrow/resolution service, which decides on a result. Another way of putting it is, a third party initiates a special type of transaction, whose contents are not revealed to the third party as long as the first two parties (buyer and seller) sign it within some amount of time.

In this system, some transaction details would be revealed to outsiders, but all the transactions that conclude successfully remain private between buyer and seller. That's better than the current situation, where one entity knows about all transactions.

Sorry for some reason I didn't see the posts past SS lol. When you have a distributed system you can start to do what you are talking about pretty easily. One thing you could do is called 'Encrypted Keyword Search'

Encrypted Keyword Search involves a set of servers holding encrypted documents, they are queried by clients with keywords (that the servers can not see), they search the encrypted documents (which they cannot actually see the plaintext of) for the keywords, and then they supply all of the resulting hits to the clients (without the servers being able to determine which of the documents they are supplying to the clients). This is a very advanced sort of cryptosystem that is actually built up by incorporating many different techniques.

1173
Security / Re: Theory: Blind markets
« on: May 10, 2013, 06:42 am »
Using a centralized blind currency mixing scheme can help solve this some. Silk Road could implement 'Silk Road Coins' (SRC) based off one of the many papers on centralized blind tokens. Then Alice can exchange 100 Bitcoins for 100 SRC. When Alice places an order from Bob she would pay him with SRC which he can redeem for bitcoins from the SR server, and because of the blinding algorithm the admin of SR will not be able to tell that Bob got the SRC from Alice, only from someone who has enough SRC to pay for the order. Since SRC could be reblinded and spent anonymously, they wouldn't even necessarily have to know who has how many SRC at any given time. A vendor could stockpile SRC for a while before exchanging them for Bitcoins, and then the admins wont even know the amount of transactions the vendor made to get those SRC since the SRC made from many deals would be mixed together into one arbitrarily sized pot. They could still collect their fee simply by charging a 5% fee for the exchanging between SRC and BTC.

As far as the product listings go, that is a little bit more tricky. It is pretty much going to be impossible to hide the products from the site admins while making them available to everybody else, because as was previously mentioned the admins could just make accounts themselves. It will also be hard to separate the listings from the vendor offering them without removing the ability to do reviews on vendors. You could break the review system apart into reviews on single product listings rather than reviews on vendors with many listings, but that will make scamming easier (also you would need open anonymous registration for all vendors and customers, so no more charging for vendor accounts. Perhaps you could charge a smaller fee for individual listings, payable with SRC). Many of the things you are mentioning could be done, but not with a centralized design. So with a centralized design I think you can have a 'taxed' market where transaction details (who is paying who for what) are hidden from the site admin, but the product listings (what is available) would need to be publicly available.

Maybe if you clarify the specific requirements of what type of system you are looking for, I will be able to think of a way to do it. Right now I am a little shaky on the details of exactly what criteria you want this market to meet. 

edit: actually if anybody can anonymously exchange BTC for SRC, the site admin wont even need to know who has how many SRC at all, vendors or customers.

1174
I think the future of hidden service databases is going to be based on blinded ECDH keys

1175
oooh another thing you could try is simply enumerating all the nodes by aggressively peering and having a few nodes yourself, and then send someone a message with an ack and wait and see how long it takes them to acknowledge. If they almost immediately acknowledge, either themselves or through a middle node, then you can assume that they are one of the nodes on the network (default behavior is to publish acknowledgements shortly after getting them). If they don't acknowledge for half an hour or so, you can assume they are not any of the nodes on the network currently. Now keep track of nodes on the network by continuing to aggressively peer, and see the nodes that are on the network when you get the acknowledgement. The person you sent the message to is likely one of the people who recently joined the network, either that or the person who acknowledged is a middle node for the person who you sent the message. Do this again when the potential middle nodes are offline, if the recipient acknowledges before the middle nodes come online you can write off the offline potential middle nodes as being your contact. Over enough node churn and acknowledgements you can likely quickly determine your contacts IP address.

1176
I think the best attack against BitMessage is this:

Add a few nodes to the cluster and peer up with many nodes. Send the target address a message with ackdata. Wait to see the ackdata published anywhere, to know the target got the message. Quickly send getdata messages to all peers requesting the ackdata msg. Create two lists, one containing all peers that have the ackdata msg and one containing all peers that do not. The peers that do not have the ackdata msg can be eliminated as suspects. Rinse and repeat until there is only one suspect. Only sending getdata messages to the suspect nodes to speed things up.

The same can be done in reverse. Every time you get a message from the target, quickly send getdata messages to all nodes. Make your two lists again, and wait to get enough messages to identify the target.

If nodes never include messages sent from them in their inventories the attack can be inversed, looking for the node that doesn't have the message listed.

This intersection attack probably identify the IP address of a sender or receiver pretty quickly, and it only actually requires having a single node so long as it is peered with the entire cluster. Since clusters are inherently destined to be relatively small due to scalability issues, it should never be hard to peer with enough nodes to carry this attack out, especially if you have a few nodes on the network.

The reason I think this is the best attack is because it can be carried out by a very weak attacker, internal with a single node.

It looks like Bitmessage waits 0-10 seconds per peer to send a newly inserted message to every node on a clients peer list. It uses 32 threads for outgoing messages, I assume it replaces them as it goes. So assuming there are 1,000 nodes on the network and they all peer with each other, and assuming it takes only 1 second to send the message to each peer, that means it will take 31.25 seconds for the client to send its message to all peers. If Alice is in the set of 32 nodes the inserting client originally sends the message to, and she quickly queries all her peers to see if they have the message, (let's say she has a modified client that uses 1,000 threads, and it takes her 1 second to query nodes to see if they have the message), Alice will have a suspect list of 64 nodes that could have sent the message.

In the case of acks Alice doesn't even need to wait to see it published actually, she can constantly query all of her peers for it with its inventory vector (which she knows as she makes the ack data in the first place and the inventory vector is just a hash of it). This will probably be even more effective actually, as as soon as a node gets a message it has the ack for it and will respond to a getdata query for the ack I assume.

Another good attack would be sending a getpubkey message to a single node and seeing if it immediately responds to you.

1177
nope nobody knows anybody actually, it integrates with Tor hidden services for routing nodes and regular Tor for clients.


 I was going to register on the BitMessage forums and give them some advice, but they block Tor from registering so fuck em.

1178
Does anybody have any clue why BitMessage sends the public ECC keys encrypted in the body of the message? That makes no sense at all to me.

1179
It is not my system (neither the design nor the implementation), I am just advising the people implementing it some. It is also not their design but is entirely from academic whitepapers from accomplished security experts in academia.

I don't want to say much, but in general, layer encrypted, multi-node routed, time delayed, uniformly padded messages mixed with cover traffic for forward anonymity, distributed PIR (not everybody gets everything or information theoretically secure though) for message retrieval, ECC, AES-256-CTR for message payload encryption.

1180
Conclusion:

Bitmessage looks something like a hybrid of Bitcoin and Freenet Frost. In other words it looks like a greatly watered down version of Freenet, but using an everybody gets everything distributed PIR based on bitcoin instead of a demand based redundant distributed storage cache where everybody gets somethings + what they want. The lack of link level encryption (which is an enormous flaw), as well as the lack of swarming and padding, has opened it up to deanonymizing attacks by local external adversaries that Freenet is protected from. It supports a mode that attempts to give plausible deniability to all users, but instead of having this behavior set as default for all clients, it has it as an optional setting for some clients that they hope will give deniability to all clients. Because everybody gets and tries to decrypt everything, it is much less scalable than Freenet. Additionally, Bitmessages plausible deniability system is fixed at using one layer of indirection, whereas Freenet uses a variable number of indirection layers that can get very deep. The incorrectly used RSA at first, and the still suboptimal usage of ECC today, makes it not something I would want to trust to do my encryption for me.

Its one real advantage over Freenet is that it uses an information theoretically secure PIR for message retrieval, rather than relying entirely on plausible deniability and link level encryption. This advantage is entirely negated by its many other shortcomings, which leave an overall impression of having been designed and implemented by amateurs.  No offense meant to any of the people who worked on it, everybody starts somewhere and the first security oriented things we design and make are likely to be horrible. I just hope that when such things are made, they are not used in a security critical fashion by people, until the flaws are fixed.

1181
4. General weirdness

A. They do an out of band transfer of address, which is the encoded hashes of the ECC public key(s?), instead of doing out of band transfer of the encoded ECC public keys themselves. The addresses are used to query the network for the public keys.

Requesting public keys in this way is probably an attack vector, if an attacker can tell who requested the public key then they can obviously link the communicating parties together. Since there needs to be an out of band information exchange in order to get the hash of the public key, why not just use an out of band exchange of the public key and have the address of the party BE their public key instead of the hash of it? That makes a hell of a lot more sense, and base58 (wtf) encoded SHA512 hashes of ECDH public keys are going to be of comparable size to encoded ECDH public keys themselves.

B. I don't think they actually need to use a different ECC key for ECDSA and ECDH if they go about it correctly. It is funny that they do for ECC but didn't for RSA where they definitely should have.

1182
3. Anonymity concerns

A. In addition to scaling horribly, when it cannot scale any more it splits into sub networks

Quote
If all nodes receive all messages, it is natural to be concerned about the system’s scalability. To address
this, we propose that after the number of messages being sent through the Bitmessage network reaches a
certain threshold, nodes begin to self‐segregate into large clusters or streams. Users would start out using
only stream 1. The stream number is encoded into each address. Streams are arranged in a hierarchy.

This reduces the anonymity set size of the system to the userbase of an individual cluster. Essentially it breaks apart one giant everybody gets everything PIR network into a bunch of little everybody gets everything PIR networks. It also opens up room for a Sybil attack, an attacker could flood clusters with malicious nodes that fake network activity in the hopes of drowning out the number of legitimate users per cluster. They can filter off their own traffic and that could severely degrade the anonymity provided to the legitimate clients. Definitely see a lot of room for anonymity attack vectors based on segmentation of the network.

B. Clients acknowledge when they have received a message, opening it up to anonymity and security attacks

Quote
One thing I noticed is that clients sends acknowledge messages when they are able to decrypt a message. I realized that this could probably be used as a side channel to recover the user’s private key.


This can also be used as a deanonymizing attack. Alice is a local external attacker who observes IP address Bob. Over a period of several days, she monitors the amount of traffic Bob gets from the network and the amount of traffic Bob sends into the network. After getting this baseline measurement of Bobs activity, she sends 100 messages to a Bitmessage address of interest. If she observes Bob's outbound traffic increasing from average, and it correlates with the number of acknowledgements he has sent back into the network, Alice can correlate this and assume that Bob is linked to the Bitmessage address she sent all of her messages to.

To be fair the network also supports passive mode of operation, where Bob does not send acknowledgements to messages. However this is not the default behavior. It certainly should be. They also offer an alternative where Bob uses a number of middle nodes to send his message acknowledgements from. This is not adequate to protect from the previously mentioned attack, as Bobs outbound traffic will still increase significantly from his average in order for him to acknowledge all of Alice's messages to him.

C. Nodes keep an up to date index of all messages they have seen, and it can be remotely queried by design

Quote
This  structure  references  inventory  vectors.  Inventory  vectors  are  used  for  notifying  other  nodes  about
objects they have or data which is being requested. Two rounds of SHA‐512 are used, resulting in a 64
byte hash. Only the first 32 bytes are used; the later 32 bytes are ignored. The rationale for not using SHA‐
256  is  that  Bitcoin  uses  SHA‐256  throughout,  including  for  the  proof‐of‐work  for  blocks.  Bitmessage
should use a different algorithm so that using Bitcoin mining hardware to do Bitmessage POWs is at least
not  completely  trivial.  SHA‐512  is  used  throughout  Bitmessage  (except  for  certain  places  within  the
encryption implementation). Changing the POW algorithm to one designed to run “poorly” on GPUs and
custom hardware would be a positive change but rapidly developing GPGPU hardware makes it difficult
to judge what algorithms will be appropriate in the future.

So if Alice sends Bob a message, and then Bob sends Alice a reply to the message, Alice can query the inventory of every node on the stream and eliminate all nodes that don't have her message from possibly being Bob? That is an intersection attack that can likely quickly narrow in on Bob. Or can Bob get a message from Alice, and then query all nodes to see if they also have the message from Alice? That will make Alice weak to an intersection attack as well. Do that over a few messages and intersect the crowds, that will quickly allow Bob or Alice to identify each other, or at least greatly narrow in on their anonymity set sizes. There are solutions to this problem but they can find them out themselves ;)

D. Clients may clear their caches in a predetermined time based fashion

Quote
Using  this  model,  Client  1  downloads  all  objects  stored  by  Client  2.  We  propose  that  each  client  store
objects for about two days and then delete them to reclaim disk space.

Do they store for exactly two days , down to the micro second, after they receive the messages? If so Bob can continuously query nodes for messages sent by Alice, and follow the messages progression through the network backwards by observing which nodes clear their caches first.

E. Can we count on them to use new initialization vectors for messages rebroadcast due to lack of acknowledgement? Probably not, given their previous crypto blunders.

Quote
If the receiver of a message is not
online  to  receive  it  during  the  two‐day  window,  the  sender  will  notice  that  he  never  received  an
acknowledgement and will resend the message after waiting an exponentially increasing amount of time.

Hopefully they encrypt it again with a new IV (hopefully they know what an IV is....) before resending it, or else another intersection attack is possible. If somebody resends the same exact ciphertext twice, it wasn't likely being sent to a person who was online in a two day period.

F. They are counting on sleeping to protect from cryptographic timing attacks that can be turned into anonymity attacks

Quote
Else if the decryption is not successful:
Sleep for a calculated amount of time (0.3 to several seconds depending on the
size of the message and the speed of your computer). Thus decrypting or
failing to decrypt the message will take the same amount of time.

Their solution to this problem is almost certainly bad. The answer to this sort of problem is pretty much invariably to implement constant time operations that are not based on timers / sleeping, but the actual logic of how the task is carried out. I would bet money that their solution to this problem is not secure. It is also horribly inefficient for the node to be trying to decrypt every single message anyway. Adding artificial time delay on top of that is going to slow things to a crawl. I don't understand how they have determined that they have failed to decrypt a message. You can decrypt a message with a key it wasn't encrypted for, it just produces gibberish. They should just decrypt all messages and then it is constant time and they don't need to sleep.

G. Intersection attacks out the ass

Let's say there is an attacker A and the network consists of 8 nodes, A[1..3], B, C, D, E, F.

A sends Bob (who is node B) a message. After getting the message, Bob sends an acknowledgement, which takes this route :

B -> C -> D -> A[1] -> F -> A[2] -> E -> A[3]

Now the attacker can conclude that Bob might be nodes B, C or D, but he is not nodes F or E. Over enough acknowledgements, or even messages sent in general for that matter, the attacker can narrow in on which node Bob is. This is an intersection attack.



They are a bit safer from internal than external attackers:

for example, assume Node 1 is the attacker and Bob sends an acknowledgement through it:

Bob -> Node 1 -> Node 2

Node 1 cannot tell that the acknowledgement originated at Bob, just as Node 2 cannot tell if the acknowledgement originated at Node 1. This is very similar to Freenet, although apparently with out link level encryption (they should really add link level encryption....)

Code: [Select]
Bob -> Bobs ISP -> Node 1 ISP ->  Node 1  -> Node 1 ISP  -> Node2 ISP ->   Node2  -> Node 2 ISP

in this case, Bobs ISP can tell that the message originated at Bob, because there is not data incoming for all the data outgoing. Just like Node 2's ISP can tell that the outgoing data did not originate at Node 2, because there is a byte in for each byte out.

The attacker at Bobs ISP who is also forcing the unknown owner of Bobs address to send a lot of acknowledgement messages can still send Bobs address a lot of messages and wait for acknowledgements to be sent. First they observe Bobs in and out traffic ratio over a period of some days to establish an average, then they send Bob 100 messages and wait for acknowledgements. Now they compare Bobs in:out ratio average over the observation period to Bobs in:out average over the period around when they sent Bob 100 messages. If bob sends a number of bytes more out than he gets in, that correlates with the number of messages the attacker sent Bob, they can guess that Bob is their target. They can also rule out nodes that don't have an in:out ratio consistent with someone who acknowledged 100 messages. This is the case if Bob forwards on the message intended for him in addition to the acknowledgement included encrypted in the message. When Bob gets a message of 50 KB that has 49KB of acknowledgement data in it, he will have 50 KB in and 99KB out (50KB out to rebroadcast the original message, 49KB out for the separate acknowledge message). If the attacker sends Bob 100 such messages, they will cause him to take in 5,000 KB  and send out 9,900 KB, a ratio difference the attacker will notice at their position at Bobs ISP. The nodes Bob routes these messages to will be getting 9,900 KB in from Bob and sending 9.900 KB out. And of course Bob cannot stop routing a message sent to him after he gets it, otherwise the attacker will notice that Bob got a message of 12 KB in and never sent any messages of 12KB out, then they can use one of their internal nodes to find the 12KB message and then they know it was sent to Bob.

Of course this attack is not even required though because apparently there is no link level encryption in the first place. So Bobs ISP doesn't even need to count packets, they can compare the content of packets in and packets out and only pay attention to packets out that don't have a data equivalent packet in.


H. Lack of link level encryption fucks anonymity up entirely from a local external attacker

The lack of link level encryption actually completely ruins unlinkability of communicating parties in the face of a local external attacker. If Alice requests the public key of Bob through the network, her ISP can see the key request coming from Alice and also determine that no key request came into Alice. Thus Alice's ISP can conclude that Alice requested Bobs public key and therefor link Alice to Bob.

Actually the lack of link level encryption totally fucks anonymity all together in the face of a local external attacker. If Alice sends a message that has her long term ECDH public key attached to it (which in itself is stupid), her ISP can see that this message was sent by Alice but did not get sent to Alice. Since Alice's address is derived from her public ECDH key, this actually let's Alice's ISP identify her bitmessage address.

I. Lack of swarming or padding messages to a constant size fucks anonymity from a local external attacker even if link level encryption is used

Actually even link level encryption is not perfect. If Alice's attacker owns an internal node on the network and is also local external, they can determine that the message originated at Alice by counting packets in and out like before, and additionally they can determine the size of the message by counting packets. Now when a message of that size passes through their internal node, they can determine that this is the message Alice sent by size correlation and now they can get Alice's address from the message + they already know her IP address from their local external positioning. Maybe they should look at Freenet some, Freenet solves this problem by swarming messages split up over several nodes, with each message chunk being the same size. The way Freenet does it, the attacker can still count chunks in and out from their local external positioning, but when *some* of those chunks pass through their internal nodes they are the same size as all other chunks.

1183

2. The implementers apparently do not understand cryptosystem basics:

Quote
However, although the fundamental ideas behind BitMessage are both innovative and sound, BitMessage as it is is not without its flaws. One blogger wrote a scathing review of BitMessage’s security, pointing out that it made a number of elementary mistakes in implementing its encryption algorithms. First, it uses RSA on the message directly rather than using it to generate a one-time key which is then used to encrypt the message, a basic modification which both drastically increases speed and prevents many attacks based on specifically constructing blocks to exploit the algorithm’s mathematical properties. Second, it independently encrypts each block rather than using an encryption mode like cipher block chaining which makes the contents of the encrypted blocks dependent on each other. This means that an attacker can rearrange the blocks of an encrypted message, which it will appear to the receiver as a valid message, as if the original sender intended for the message’s blocks to come in the attacker’s chosen order. Finally, the encryption algorithm does not include an authentication layer, making other kinds of attacks possible. However, BitMessage developer Jon Warren is aware of these flaws, and is working hard on creating another version of the protocol that fixes these issues.

A. At first they used RSA to directly encrypt messages one block at a time. This is not how RSA is supposed to be used, rather it is supposed to be used for encrypting a session key that is used for symmetrically encrypting/decrypting payload data. This is like running RSA in ECB mode to encrypt payload data. First of all you don't use RSA to encrypt payload data and second of all you don't use ECB mode. This is a very bad cryptosystem implementation, probably about as bad as possible while still using secure primitives.

B. They had no authentication at first either. It is pretty apparent from their initial effort that they are not qualified to implement a security critical system, and even though they are apparently making some fundamental changes, the fact that they fucked up so badly on their first try is not confidence instilling. The mistakes they made at first would not have been made by someone who had read an introductory book on cryptosystem engineering.

C. They are relying on proof of work, which is probably helpful, but not something that should be relied on very much. Read the paper proof of work proven not to work, for example.

D. They used the same RSA key for signatures and encryption, commonly known as improper use of RSA

E. Now that they have switched from RSA to ECC, in order to address their improper use of RSA, they still appear to be using ECC weirdly/inappropriately. For example it seems as if they are using long term ECDH public keys for shared secret derivation, but they should be using ephemeral keys for this on a per message basis.

F. What is up with their message structure?

Quote
Each  node  attempts  to
decrypt the message with each of their private encryption keys and also passes the message to peers. Bob
decrypts  the  message  then  checks  the  signature  using  the  public  signing  key  included  in  the  message.
Finally, he hashes the public key in order to create the base58 address to display in the user interface. By
default, he will also send an acknowledgement which is also included in the message from Alice.

So the public signing key is encrypted with the message? What? Why not use message authentication codes and sign messages with the long term EC private key with ECDSA? Are they using ephemeral public signing keys and long term public secret derivation public keys?! That is not a good way to use ECC (actually it is the opposite of how it should be), they are not understanding how to use it right. If their public signing keys are not ephemeral why are they including them encrypted with every message?? If they are ephemeral, what is the point of an ephemeral signing key, did they mean to use message authentication codes?

 

1184
disclaimer: I am advising on a messaging system that will compete with Bitmessage. That said I was objective in my analysis, to the best of my ability anyway.

I am going to take all of the information from my previous posts and make one single big post, with better organization.

Here is kmfkewms consolidated analysis of Bitmessage, based off the two published papers and some news articles:

Basic Information:

Bitmessage is an everybody gets everything PIR (private information retrieval) system that also has worked in a message publishing (hence forth referred to as inserting) system.

Concerns:

1. Inefficient

Quote
Just like Bitcoin transactions and blocks, all users would receive all messages. They would be responsible
for  attempting  to  decode  each  message  with  each  of  their  private  keys  to  see  whether  the  message  is
bound for them.

A. They use everybody gets everything PIR. Although this is information theoretically proven as anonymous to within the set size of users, it is horribly inefficient. If they settled with computationally secure, rather than information theoretically, they could reduce the amount of required bandwidth by orders of magnitude. Everybody gets everything is an elementary form of private information retrieval, there has been over a decade of research into PIR greatly improving on its current state (largely efficiency and scalability) versus everybody gets everything. Everybody gets everything PIR is roughly equivalent to the one time pad of symmetric encryption, information theoretically secure but impractical. 

B. They have ALL nodes attempt to decrypt ALL messages. This is horribly horribly inefficient and CPU intensive, and will not scale. There are better solutions than this. Here is an example from me:

Quote
I don't want to give away too much simply because I am working on a competing system, but I will share this. Have the users pairwise exchange random string pairs. Alice gives Bob:

6d7ebc44c5bc26207e62f4f628f912e1a0f41ed11764891aa7dd99eab83228e7 , 19732980d68fbd00358a0a4d98246c960400b87e4fa2a2e155db98be2b42ed6c

Bob also gives Alice a string pair. The first message Alice sends to Bob is tagged with the hash of the concatenation of the two strings:

82b77ccc6b3596d6c16fffc35d68611faf28953ae8708ba0aa56ef3ff7df6288

now this string replaces the second string Alice gave to bob (197...) and the next message Alice sends Bob is tagged with the hash of the concatenation of the string pairs again:

9737f35b450c69e40dca253815b2a593c3fd56eaa30e69878bedab0106423563

etc. Now Bob can keep a record of the strings that could indicate a message from each of his contacts, and he only needs to try to decrypt the messages if they are detected as having been encrypted to him. A passive attacker can see the strings messages are tagged with, but they cannot gain any information from this without knowing the original strings in the pairwise key exchange between Alice and Bob. Now Bob is not exhausting his CPU trying to decrypt hundreds of thousands of messages. I am not going to go into any more detail than this (trust me there is a lot more detail than this) but that is a basic signaling system that is certainly better than 'everybody tries to decrypt everything'. 'everybody gets everything and everybody tries to decrypt everything' is a recipe for failing to scale, and it is entirely not required.

Since they are using ECDH now they can use multiple iterations of hashing the derived shared secret between long term keypairs to pairwise exchange the initial tagging string pairs. I remain hopeful that they use ephemeral ECDH keys for deriving secrets for actual message encryption/decryption (hey at least now they cannot directly encrypt the payload data with the public key cryptosystem!).

1185
Off topic / Re: Official Grand Theft Auto Thread
« on: May 07, 2013, 12:13 pm »
Have not played GTA in a long time (what, last year or something?).

Hate the outdated graphics.

Welcome to enb. look up GTA IV enb.

Pages: 1 ... 77 78 [79] 80 81 ... 249