ES2709074T3 - Comparison of an automated contact list with an improvement in privacy - Google Patents

Abstract

A method for comparing a first plurality of private data sets, such as a private address book stored on a communication client device (12), with a second plurality of data sets, such as a large repository of contacts stored on a communication system. server-based communication (14), comprising the steps of: a) said server system receiving for each of said first plurality of private data sets a reduced hash value (28) from said client, preferably in a communication channel encrypted transmission, with a request to compare said private data sets with said second plurality of data sets stored on said server, wherein said reduced hash value has a length s representing the number of bits of a cryptographic hash value of a single party, preferably a phone number from each of the private data sets to be transmitted between the client and the server or, wherein s is chosen such that hash collisions will occur in said server-based communication system (14), b) said server compares (240) each of said received and reduced hash values (28) with said second plurality of data sets stored in said server, and finds the data sets stored among said second plurality of data sets having an identical reduced hash value, c) said server lists (245) each of said found hash values with a respective one of said received and reduced hash values (28), d) said server sending (250) said found hash values (28) to said client device.

Description

DESCRIPTION

Comparison of an automated contact list with an improvement in privacy

1. Background of the invention

1.1. Field of the invention

The present invention is in the field of information technology and is related to a method and system for comparing a first plurality of private data sets, for example, a private contact book typically having a few hundred entries. of contacts, stored in a communication client device, with a second plurality of data sets, for example, a large contact repository having thousands or even millions of contact entries, stored in a server-based communication system.

1.2. Description and disadvantages of the prior art.

The popular communication services of the prior art that run on smartphones such as WhatsApp use the user's GSM telephone number as the user's identity. They provide services such as text messages, voice calls over IP and file transfer, at low cost, by transferring data through the telephone's Internet connection. To show the user the subset of their contacts who are also members of the same communication service, they compare the user's contact list with the set of already registered members of the communication service.

So far, in the prior art this is done by sending the list of telephone numbers to the service provider without encryption and without anonymization, as reported in the magazine of "Stiftung Warentest", volume 6/12, published on May 24 of 2012, receiving in response the subset of contacts that are already members. Therefore, anyone who can listen clandestinely to the communication between the phone and the service provider gets access to the user's full contact list. This includes the service provider itself, of course. However, a contact agenda constitutes private information and is a trade secret for professionals, which reveals valuable contacts and, possibly, even commercial strategies.

In order to be able to provide the service requested, for example, to show the online status of the contacts, the contacts of the user's members must be disclosed to the service provider. This is allowed because those contacts have accepted the terms and services of the communication service. In contrast, contacts that do not participate in the communication service should not be disclosed publicly, not even to the communication service provider. In fact, this would be a violation of the contact information right ("Grundrecht auf informationelle Selbstbestimmung") of the contact, who probably has not accepted that their information is shared with that service provider, as reported in http: //www.telemedicus .info / article / 2222-LG-Berlin-Das-Facebook-Urteil-im-Detail.html.

as published on the Internet since March 12, 2012, or consult the published decision of Landgericht Berlin, LG Berlin, Urteil v. 06.03.2012, Az. 160551/10.

A perfect sensitive form with privacy would be to asymmetrically encrypt the list of telephone numbers, entry by entry on both sides with a random and unique key, and compare the encrypted lists. Since the cipher is bijective, it is a bisection in the intersection operator, so the client can easily transform the result backwards. However, encrypting all the telephone numbers of a member in each comparison is computationally unfeasible, since there could be millions, and multiple queries per second could occur. Another way would be to send the complete list of customer service participants and compare them there without further interaction with the server. However, this is also unfeasible because it would reveal the contact information of all service members to an unreliable user. Moreover, the very long list of members would have to be sent to the client, which would possibly result in many megabytes of data, which is not feasible, especially for mobile clients.

1.3. Objectives of the invention

The aim of the present invention is to provide an efficient method and system for transmitting and comparing said private data, as mentioned above, in which the data is processed in such a way that any person who listens clandestinely, including the service provider central that really makes the comparison, also have to devote an intensive computer work if you want to know about the data, and which procedure does not consume too much computational capacity in the client and server devices.

2. Summary and advantages of the invention.

This object of the invention is achieved by the features set forth in the appended independent claims. Other arrangements and advantageous embodiments of the invention are set forth in the respective dependent claims. Next, reference should be made to the appended claims. According to a basic characteristic of the present invention, a method executed in a server for comparing a first plurality of private data sets, such as a private contact book and stored in a communication client device with a second plurality of data sets is described. , as a large contact repository stored in said communication system, comprising the steps of: a) the server computer that calculates the length of the hash value s that represents the number of bits of a cryptographic hash value of a single part (per example, the telephone number) of each of the private data sets that will be transmitted between the client and the server, and that communicates to the client,

b) the server system that receives for each of said first plurality of private data sets a reduced hash value from said client, preferably in an encrypted transmission channel, with a request to compare said private data sets with the second set of data stored on the server, c) the server checks if the received hash length is equal to,

d) if the hash length is equal to s, the server compares each of the received hash values with the second plurality of data sets stored in the server, finding the stored data sets that have an identical reduced hash value,

e) the server lists each of said hash values found with a respective one of said received hash value, for example: 10 received hash values, 23 matches found

f) the server reduces the hash values found, that is, the complete hash values, to a predetermined length of m bits, and

g) the server sends for each of the reduced hash values and received the list of reduced hash values to the client device, in response to the previous request.

The processing of the parameter s in step a) is a less important stage, a kind of preprocessing. The parameter s can also be configured manually or automatically in general or individually for each use example. The client and server computer perform the respective likelihood controls and agree on a specific value regardless of which party proposes it: client or server, or agree a maximum difference allowed between s as it is sent from the server, and s, as sent from the server. client.

In step b) above, in the case of collisions in the address book, that is, when two different private data sets accidentally have the same hash value, then only this unique hash value is sent from the client to the server.

A cryptographic hash function like SHA-1 (previous technique) projects each telephone number in a bit string of a certain length, called hash, for example, 160 bits. A cryptographic hash function is a unidirectional function. Therefore, determining the previous image, that is, the telephone number of the hash, is computationally difficult. In general, it is assumed that the only way to obtain the previous image of a hash is to test most of the previous possible images. In fact, it is expected to find a match after having tried half of them, but in the worst case, you have to try them all. In the next paragraph, we are going to ignore this small constant factor of 2.

Recalling the length s in the sense of the present invention means selecting an arbitrary but systematic subset of s-length hash. For example, you could select the first ones (as shown in the drawings) or the last bits, or arbitrary bits, such as the 1st, 4th, 3rd, 21th and so on. The way in which the subset is selected has no influence on the quality of the invention, since all the bits have the same properties, which is a feature of a cryptographic hash function. The only condition is that the server and the client agree on the same subset and that the two bits of the same bit position are compared with each other.

Steps a) and c) can also be replaced by an alternative procedure that produces control parameters usable in the method of the invention.

As for step f), a second reduction can also be omitted, when the parameter m is set to the total length of the hash, for example, 160 bits in the SHA-1.

The method of the invention can be applied advantageously when the private data sets are contact data stored in a mobile computing device, such as a smart phone or a mobile phone, since the computational capacity in said devices is, although it is constantly growing. , still quite limited.

When additionally, the server computer stores a reduced and precalculated hash value for each of the private data sets, which has been calculated with the same algorithm that was used in the client computer, no hash calculation must be performed "on the march ", that is, when a request for comparing contacts is received on the server. This saves time and allows short response times for such requests. In addition, the server computer advantageously calculates and stores a hash value of average length m that it will send back to the client for each data set of the comparison.

The client then compares said average length hash value with the prefix of the complete hash value, and for a matching pair, the client can easily calculate the respective private data set that has been compared by the server. Therefore, said average size hash value used in the server also saves time and allows short response times for said comparison requests.

When the server computer repeatedly calculates the hash values based on an input parameter preferably calculated randomly, for example, what is generally known as "random salt", then there is some measurement against the use of the so-called tables of the rainbow by a possible attacker.

In an analogous manner as described for the server side, also for the client computing device, preferably a mobile device, a method is described for comparing a first plurality of private data sets, such as a private contact book and stored in a communication client device with a second plurality of data sets, such as a large contact repository stored in a server-based communication system, comprising the steps of:

a) the client device that processes or calculates a predetermined hash value length s that represents the number of bits of a cryptographic hash value of a single part, for example, the telephone number of each set of private data to be transmitted between the client and the server,

b) the client device that calculates the hash value for each of the private data sets,

c) the client device that reduces the hash value for each of the private data sets to a predetermined length s,

d) the client device sending, for each of the private data sets, said reduced hash value to the server, preferably on an encrypted transmission channel, which requests the server to compare the private data sets with the second plurality of data sets. data stored on the server,

e) receiving a hash value for each comparison, whose hash value has been reduced to a plurality of a predetermined number of m bits by the server,

f) the client compares the received and reduced hash values to am with the data sets stored in the client, thus revealing information on which private data sets and stored both in the client and in said server, the unique and respective portion is identical .

Advantageously, the client's computing device iteratively applies the calculation of the hash value repeatedly and multiple in order to provide a greater degree of privacy.

The skilled reader recognizes that, mathematically speaking, the comparison problem solved here is to find the intersection of the relatively small set of contacts in a user's contact book with the relatively large set of a repository that stores a large plurality of contact data. of the registered members of a respective communication service, through a limited bandwidth connection. The special requirement is to protect privacy. The contacts and the members are identified in this use example by their telephone number in the unique and internationally standardized format, for example, 4199999999.

Thus, a person skilled in the art will appreciate that an advantageous method and system is described that offers a protocol for comparing private data and, in particular, for comparing the contact list with a contact repository of a communication service, in which the protocol does not disclose private information or the service provider or any third party. Therefore, the anonymity and privacy of the user's contacts are maintained, and the contacts are not exposed to clandestine eavesdropping.

According to an additional advantageous optional feature, all hash values also include a salt, that is, which results from a random, but constant bit string, added to the private data set, for example, added to the telephone number, to the name or any part of the private data set, in a clear way that deterministically changes the hash result. After predetermined time intervals, the service provider recalculates all member hashes based on a new random salt, disapproving a possible inverse hash table (rainbow table) calculated by a brute force attack. By telling the user to use this new When comparing contacts, the service provider demonstrates the great effort it would take to apply reverse engineering in the user's phone book, even for themselves.

With this method of the invention, it is not practically feasible for the service provider or clandestine listeners to reverse engineer the contact agenda. Here, practically unfeasible means that it requires a prohibitive computational effort. And even if clandestine listening dedicates this effort, there is still the uncertainty of whether a contact reproduced by reverse engineering is really a contact, for example, 50%, depending on certain parameters, which can be configured and modified by predetermined parameters adaptable to any example of individual use.

In addition, the anonymity and privacy of contacts who are not members of the communication service are preserved, since contacts that do not participate can not be known accurately, not even by the service provider. The service provider knows only the contacts that are registered for the service, that is, that they have accepted the terms and conditions of the service provider in any case.

Therefore, a method of the invention is described which includes the technical characteristic of applying hashing to the entries in the contact book and preventing brute force attacks by not transmitting the complete hash, but only a well-chosen part. This introduces uncertainty into any brute force attack but maintains the expected hit rate when providing a reliable comparison of contacts. The parameters are chosen to optimize privacy against bandwidth requirements.

However, the procedure and the respective system are effective in terms of calculations and communication even for a large number of members, possibly for all telephone numbers used on Earth.

3. Brief description of the drawings

The present invention is illustrated by way of example and is not limited by the shape of the figures of the drawings in which:

Figure 1 is a general schematic description of the system involved in the method of the invention. Figure 2 is an interaction diagram illustrating the interaction between the client and the server during a preferred embodiment of the method of the invention.

Figure 3 is a zoomed-in view of a detail of a stage of Figure 2 that is executed by the client.

Figure 4 is a schematic and exhaustive representation that illustrates a reduced hash value, a medium-sized hash value and the user's clear reference, in this case the name of a person, for three different entries in the contact book.

4. Detailed description of the preferred embodiment

With general reference to the figures and, again, with special reference to Figure 1, the method of the invention is implemented in a client-server architecture as represented in Figure 1.

A mobile client smart phone device 12 is connected through an Internet connection 10 to a server computer 14 operated by a service provider. The server computer stores a large plurality of, for example, several million contact records in a large physical repository, organized in an indexed database, for example, a relational database, in which each data set is associated with an individual who has subscribed to the service before their contact information is stored. The contact information includes one or more physical addresses of your position, telephone numbers, email addresses and, optionally, other data such as sex, age, profession, date of birth, salary and other data that may be relevant for purposes of marketing, such as hobbies and interests, body size, etc. The client device and the server computer communicate with an encrypted connection through the Internet, such as the TLS protocol as known in the prior art or, additionally, with a protocol, for example, as described in an application number. European patent application 12007079.2 filed by the applicant.

In addition, symbolically represents an attacker 19 that attempts to attack the communication on its way through the Internet, with technical means of clandestine listening to the previous technique.

In addition, it is assumed that a second attacker works on the service provider's site, perhaps a staff member, for example, a malicious database operator 20 that has read and / or write access to the repository.

The comparison procedure of the invention is referred to herein as Private Contacts Comparison and is abbreviated as CCP. Let in this exemplary embodiment of the method of the invention, the "client" is the mobile computing device in which the user executes a communication application, for example, "Facebook" or "Twitter" or "WhatsApp", implementing the procedure CCP of the invention incorporated in a respective App. It communicates with the "server" of the communication service provider, implementing the equivalent CCP procedure and, therefore, interacting with the client.

Figure 2 is an interaction diagram illustrating the interaction between the client 12 and the server 14 during a preferred embodiment of the method of the invention.

Figure 3 is a zoomed-in view of a detail of steps 225 and 230 of Figure 2, executed by the customer. As a first security measure, it is preferred to encrypt the Internet connection 10 between the client and the server using the security of the transport layer called TLS, as is done in the prior art. By verifying that the server certificate belongs to the service provider, it is guaranteed that only the known and desired service provider can listen to the communication, so that the protocol can not be easily heard clandestinely by a third party, such as the attacker 18 of Figure 1.

Second, according to a preferred feature of the present invention, the telephone numbers 22 of the customer's contacts are not transmitted in plain text, but are processed by a specific cryptographic procedure, in particular, by means of a cryptographic hash function, such As is known from the prior art, the function MD-5 or SHA-1, in step 225, the method of the invention projects each telephone number in a bit string, called hash (value), which is reduced in the step 230 and subsequently transferred to the server in step 235.

More particularly, and preferably, before performing the steps 225 to 235 mentioned above, when initiating the session during the client request stage 210 and the login session granting stage of the server 215, the server calculates the value s = floor ( log_2 (n)) - u as an indication of how many bits per contact should be sent in a possible comparison procedure in a step 216 and communicated to the client in a step 219. The client receives said parameter s and verifies if this value is reasonably small. Alternatively, the customer can decide which values to use based on any other criteria.

Then, in a step 225 and with a special additional reference to Figure 3, for each contact in the contact list that must coincide with the server's contact repository, the client calculates a cryptographic hash value of the telephone number 22. Preferably, and by way of example, the SHA-1 algorithm is used and a salt is added in a step 310 before applying the hash function to the telephone number with added salt 24 in a step 320. Preferably, the hashing is repeated a large number of times, for example 1000 times (not shown in the drawing); the more times, the harder it is (directly proportional) to calculate the previous image of the hash value.

Third, the hash values of the telephone numbers in the address book are reduced to a certain number of bits in an additional step 330, which results in a reduced hash value 28, in order to introduce uncertainty in the case of the attacker applying brute force.

With reference to the special problems of this use of the invention, only the service provider can attack due to the secure transmission of TLS, but it should be noted that contacts that are not members in the server repository should not be compared, nor should even be exposed to the service provider.

Since the communication service has n, for example, n = 10,000,000 members. Let L = log_2 (n), therefore, L = 23, xxx. If L hash bits are compared, a random hash is expected to coincide with approximately 1 contact. The client cuts the hashes in a step 330 to s = floor (L) -u bits, where u is a parameter predetermined and configurable by the user. The greater the u, the greater the uncertainty, since it is expected that more members than contacts will coincide with the reduced hash. Suppose u = 1, then

s = floor (23, xxx - 1) = floor (22, xxx) = 22 = s. Therefore, the client reduces the hash value of, for example, 160 bits (in the case of using SHA-1) to 22 bits, resulting in a reduced hash value indicated with the reference sign 28 in Figure 3 Then the client sends the reduced hash list to the server through the encrypted TLS connection, see step 235 in Figure 2.

After receiving said reduced hash values, in order to avoid exposing telephone numbers to too many hash collisions with false positives, the server's CCP program checks whether the length s of the reduced hashes is sufficiently long as requested, and check in step 238, if the number of hash values sent is not unbelievably large, to avoid revealing an inappropriately large part of the set of customer contact data members. In this sense, it is proposed to define a maximum limit of the number of hashes sent to the client to 5000, as a maximum possible size for the contact list.

Subsequently, the server compares the received reduced hashes with the members of its system repository in a step 240. More particularly, the server finds the members for which the hash prefix of the telephone number matches one of the short hashes received by a respective comparison procedure. For each comparison, in a step 245, the server lists the corresponding hash value in a length of average size m, preferably longer, for example, of 64 bits, of the same type, which makes the comparison results very similar. probably accurate, but still requires a high computational effort to decipher and reveal the telephone numbers of the image prior to comparison.

Then, in response to the comparison request, instead of returning the telephone numbers in plain text, the server sends said medium-sized, longer hash values (eg, m 64 bits) to the client, step 250.

After the client has received said half-size hash values, in a step 260 the client compares the average size hash values received with the contact data itself, that is, finds the contacts for which the hash prefix of the number telephone matches one of the received half-size hashes. Each match is a contact, which is also a member of the communication service, which forms the resulting intersection of sets. The client then shows his user that the comparison procedure has been successfully completed, step 270.

In order to respond effectively to the comparison queries, the server preferably maintains the short hash value with each member data set indexed in the database, so it is not necessary to calculate the hash values on the fly. In addition, the average size hash value for the result is preferably stored in the database for rapid construction of the response.

Figure 4 is a schematic and exhaustive representation of the table illustrating in a column on the left a reduced hash value indicated in an exemplary hexadecimal code and corresponding to 16 bits, in the middle column a mean-size hash value in a code hexadecimal exemplary that corresponds to 64 bits, and the column on the right the clear reference of the user, in this case the name of a person, for three different entries of the address book. The strings of identical bits of the hashes are denoted inside the circles in dashed lines.

In a preferred effective implementation of the system in the server part, the server keeps associated with each member of the contact repository, the short hash and the medium size hash, incorporating the current salt. Stores the short hash in hexadecimal format so that an efficient indexed search can be performed. If the number of bits is not divisible by four, bits 0 are filled in both the short hash and the query.

To allow the change of the hash properties such as length and salt while continuing with the service, the new calculation that consumes a lot of time must be done as a background task. For this purpose, the server retains two

using new parameters as a background task. When the calculation is finished, the server exchanges both tables and begins to communicate the new parameters to the clients.

In addition, a brief test of the effectiveness of the method of the invention as described above is given below, along with other improvements thereto:

The connection between the client and the server is encrypted and authenticated by a server certificate well known to the client. The client is not authenticated in the server, since it is assumed that the service is open to the public in any case. Intercept encrypted communication would require write access to the client and install a forged or manipulated version of the client software. Taking into account this assumption, the attacker could simply read the contact book in plain text directly from the customer's phone and send it to the attacking party. So we can assume that the connection is secure.

In any case, the communication service provider can read the complete communication, and the staff can not be considered as completely reliable due to the privacy regulations mentioned in the introductory chapter. On the other hand, the communication service provider can demonstrate its credibility of privacy to the public through the procedure of the invention. Therefore, the expert reader understands that even the service provider could reconstruct the contact agenda only with extreme effort and, even so, only with a significant degree of uncertainty, as justified below.

We estimate that there are approximately 10A12 (one billion) of telephone numbers worldwide (including country codes). Although the actual set of phone numbers in the world is, in fact, much smaller, there is not a complete list machine-readable and publicly available that may be of help. Since the method of the invention preferably iteratively applies the hash function of the order of magnitude 10A3 times, attacking the contact book requires a computational effort of approximately 10A15 (1000 trillion) hash calculations, which is very expensive even in large computers. For the client, calculating the hash requires a lot of computational capacity, but this is acceptable (10A6, a million hash calculations for 1000 contacts), since this can occur as a background task. As the computational capacity of mobile devices generally increases over time, both in the clients and in the machines available to the attacker, the number of iterations may increase.

For the parameter u = 0 mentioned above, the expected hit rate for each hash is 1, for u> 0, it is 2Au (that is, 2 exp u). The drawback is that the larger u, the list of returned results grows, and so do the bandwidth requirements. Therefore, selecting a value for u is a compromise between privacy and bandwidth requirements. A preferred value is u = 1, so the probability that a suspicious contact is actually a contact is 50%.

Furthermore, the number of bits sent to the server in the procedure of the invention will be asymptotically smaller than the entropy of bits contained in the contact book, so that an independent party is given a clue that the contact list is not send completely, just knowing the length of the encrypted message.

For example, for n = 10A6 and u = 1, an embodiment of the invention would send only 18 bits per contact, which is equivalent to approximately 6 decimal digits, which is even shorter than the usual individual part of the telephone number (i.e. excluding the area and country code).

Since the hashes sent by the client are designed to produce hash collisions, the service provider reveals some members that are not contacts to the client, as a medium size hash. Again, the calculation of the previous image is still limited by a prohibitive effort, and even if that effort is reversed, the client only knows random members. However, it is possible to verify if there is a member with a specific telephone number, since it could easily be added to the contact agenda of the interested party and that part could become a member. After all, exposing a member that a contact is also a member of the service, is the original purpose of the entire system of the invention.

The method and system of the invention can be modified and expanded in various ways:

The Private Contact Comparison method of the invention is also advantageous when used with stationary devices with an Internet connection of higher bandwidth. The disadvantageous alternative, as mentioned in the introductory chapter, of transferring the entire set of members of the communication service, is not yet feasible in this case, since it would produce a lot of unexpected traffic on the part of the user. Thanks to a greater computational capacity available in this environment, the number of hash iterations could be increased for even better privacy.

In addition, in case the server wishes to provide multiple levels of privacy using different sets of parameters, if computer performance and bandwidth are balanced, the server can only maintain multiple sets of parameters with the respective degree of balance as mentioned. previously. The method of the invention can also be used with contact identification means other than the telephone numbers mentioned above, for example, e-mail addresses. It works even better, since the universe of possible email addresses is much larger in number and easier to administer thanks to the absence of analog communication interfaces than the universe of telephone numbers. Therefore, attacks are less likely to succeed.

While in the above description, a user is usually identified by a single telephone number, the invention procedure may also vary to support multiple telephone numbers per contact. The different telephone numbers are treated as individual contacts, which is also useful for communicating with the recipient in the desired device (eg, work telephone in front of the home telephone).

To further confuse the customer's contact list, the customer can add randomly generated virtual contacts, that is, respective data sets, behind which there is no physical person, and include the respective hashes in the comparison request. However, this does not add much to the truncation of hashes, except that it is outside the influence of the service provider.

Although the aforementioned characteristic is stained with uncertainty for the service provider in which the coincidence of a contact is actually a real contact in the user's telephone, it is possible to say with high probability if a suspect contact a priori is really the contact of a client, after executing the method of the invention, because it is unlikely a posteriori that another user contact produces the same short hash.

To make a fortuitous coincidence more likely, it is proposed, according to a further feature of the invention, to choose a parameter or larger, that is, to accept more traffic, or to make the hash function retain a large part of the original information, for example , combining the first digits of the telephone number (country code and area, which is likely to reappear and does not include private information) with a hash of the corresponding shorter telephone number. This amplifies said parameter u more effectively.

The present invention can be realized in hardware, software or a combination of hardware and software. A tool according to the present invention can be carried out centrally in a computer system, or in a distributed manner in which different elements extend through several interconnected computer systems. Any type of computer system or other apparatus adapted to carry out the methods described herein is suitable. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when loaded and executed, controls the computer system so as to carry out the procedures described herein.

The permanent storage hardware resources mentioned herein, such as hard disk drives, or optical or magneto-optical devices, such as compact discs or digital versatile disks (DVD), Flash ROM devices, are in general interchangeable in use, unless Specify explicitly differently. Therefore, for most storage purposes, a permanent, non-volatile storage device can be used, as mentioned above, when the computer system in question does not have a special dedication or relationship with being used as a system. of hand or suitable for a pocket. Of course, in the absence of a hard disk drive, a FLASH-ROM storage device is preferred.

Volatile memory is generally used to temporarily store programs or data and, in particular, to load programs or submodules of programs, and for the immediate exchange of data with the central processing unit (CPU) of a computer.

The present invention can also be integrated into a computer program product comprising all the features that allow the implementation of the methods described herein, and which, when loaded in a computer system, is capable of executing these procedures.

Means of computer programs or computer programs in the present context mean any expression, in any language, code or notation, of a set of instructions intended to make a system that has an information processing capacity perform a particular function either directly or after one or both of the following aspects

a) conversion to another language, code or notation;

b) reproduction in a different material form.

LIST OF REFERENCE SIGNS

10 Internet connection

12 mobile client device

14 server computer service provider

16 repository

18 attacker inside the Internet

20 malicious server operator

22 customer's phone number

24 phone number with added salt

26 hash value of 24

28 reduced hash value of 26

30 average size hash of 26

210 to 330: steps of the method of the invention

Claims (16)

A method for comparing a first plurality of private data sets, such as a private contact book and stored in a communication client device (12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), comprising the steps of: a) said server system receiving for each of said first plurality of private data sets a reduced hash value (28) of said client, preferably on an encrypted transmission channel, with a request to compare said private data sets with said second plurality of data sets stored in said server, wherein said reduced hash value has a length s representing the number of bits of a cryptographic hash value of a single part, preferably a telephone number of each of the sets of private data that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), b) said server compares (240) each of said reduced and received hash values (28) with said second plurality of data sets stored in said server, and finds the data sets stored between said second plurality of data sets having an identical reduced hash value, c) said server lists (245) each of said hash values found with a respective one of said reduced and received hash values (28), d) said server sends (250) said hash values (28) to said client device. 2. The method according to claim 1 wherein a) for each comparison, said server lists (245) the corresponding hash value in a bit length of m bits, wherein said bit length of m bits makes said comparison results very likely to be accurate, and d) said server sends (250) said hash values (30) with length of m bits to said client device. 3. The method according to claim 1 wherein said server checks (238) whether the length s of the reduced hashes is sufficiently long. The method according to claim 1, wherein said private data sets are user contact data stored in a mobile computing device (12). The method according to claim 1 in which the server computer (14) determines a value s representing the number of bits of a cryptographic hash value (28) of a unique part of each of said sets of private data that is will transmit to the customer and transmit said value to the customer. The method according to claim 1, wherein said server computer (14) stores a precalculated reduced hash value (28) associated with a respective private data set. The method according to claim 1 wherein said server computer (14) calculates and stores a longer hash value (30) than the one received, associated with a respective private data set and sends (250) said longer hash value back to the client for each comparison data set. The method according to claim 1, wherein said server computer (14) recalculates said hash values (28) based on a predetermined input parameter, preferably randomly calculated. 9. A method for comparing a first plurality of private data sets, such as a private contact book and stored in a communication client device (12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), comprising the steps of: a) for each of said private data sets the client device calculates (225) the cryptographic hash values, b) said client device reduces (230) said hash values to a predetermined hash value length s that represents the number of bits of a single portion of said hash value of each of the private data sets that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), c) said client device for each of said private data sets sends said reduced hash value (28) to the server, preferably on an encrypted transmission channel, requesting that the server compare, based on said reduced hash value, said private data sets with said second plurality of data sets stored in said server, d) receive a hash value for each comparison, e) the client compares (260) the received hash values with the data sets stored in the client, thus revealing information on which private data sets and stored both in the client and in said server, the unique and respective portion is identical . The method according to claim 9, wherein said hash value received from said server has been reduced to a plurality of m bits by the server, wherein said bit length of m bits causes said comparison results to be very probably accurate. The method according to claim 9 wherein said client computer (12) iteratively applies said hash value calculation repeatedly and multiple. 12. A computer system having means for performing the steps of a method according to one of the preceding claims 1 to 11. 13. A computer program to execute in a server-based data processing system (14) and implemented in a client-server network, the comparison of a first plurality of private data sets, such as a private contact book and stored in a communication client device (12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), comprising a functional component for performing the respective steps of: a) said server system receiving for each of said first plurality of private data sets a reduced hash value (28) of said client, preferably on an encrypted transmission channel, with a request to compare said private data sets with said second plurality of data sets stored in said server, wherein said reduced hash value has a length s representing the number of bits of a cryptographic hash value of a single part, preferably a telephone number of each of the sets of private data that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), b) said server system compares (240) each of said reduced and received hash values (28) with said second plurality of data sets stored in said server, and finds the data sets stored between said second plurality of data sets having an identical reduced hash value, c) said server system lists (245) each of said hash values found with a respective one of said reduced and received hash values (28), d) said server system sends (250) said hash values (28) to said client device, when said computer program is executed in a computer. 14. A server-based computer program product stored in a computer-usable medium, implementable in a client-server network, for comparing a first plurality of private data sets, such as a private contact book stored in a communication client device (12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), comprising computer readable program means including a functional component for making a computer perform The stages of: a) said server system receiving for each of said first plurality of private data sets a reduced hash value (28) of said client, preferably on an encrypted transmission channel, with a request to compare said private data sets with said second plurality of data sets stored in said server, wherein said reduced hash value has a length s representing the number of bits of a cryptographic hash value of a single part, preferably a telephone number of each of the sets of private data that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), b) said server system compares (240) each of said reduced and received hash values (28) with said second plurality of data sets stored in said server, and finds the data sets stored between said second plurality of data sets having an identical reduced hash value, c) said server system lists (245) each of said hash values found with a respective one of said reduced and received hash values (28), d) said server system sends (250) said hash values (28) to said client device, when said computer program product is run on a computer. 15. A computer program for executing in a client-based data processing system (12) and implemented in a client-server network, the comparison of a first plurality of private data sets, such as a private contact book and stored in a communication client device (12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), comprising a functional component for performing the respective steps of: a) for each of said private data sets the client device calculates (225) the cryptographic hash values, b) said client device reduces (230) said hash values to a predetermined hash value length s that represents the number of bits of a single portion of said hash value of each of the private data sets that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), c) said client device sends said reduced hash value (28) to the server for each of said private data sets, preferably on an encrypted transmission channel, requesting that the server compare said private data sets with said second plurality of data sets. data stored on said server, d) said client device receives a hash value for each comparison, e) the client device compares (260) the received hash values with the data sets stored in the client, thus revealing information on which private data sets and stored both in the client and in said server, the unique and respective portion is identical, when said computer program is executed in a computer. 16. A client computer program product stored in a computer-usable medium, implementable in a client-server network, for comparing a first plurality of private data sets, such as a private contact book and stored in a communication client device ( 12) with a second plurality of data sets, such as a large contact repository stored in a server-based communication system (14), which has a functional component to execute the stages of: a) for each of said private data sets the client device calculates (225) the cryptographic hash values, b) said client device reduces (230) said hash values to a predetermined hash value length s that represents the number of bits of a single portion of said hash value of each of the private data sets that will be transmitted between the client and the server, in which s is chosen so that hash collisions will occur in said server-based communication system (14), c) said client device sends, for each of said private data sets, said reduced hash value (28) to the server, preferably on an encrypted transmission channel, which requests the server to compare said private data sets with said second plurality of data. data sets stored on said server, d) said client device receives a hash value for each comparison, e) the client device compares (260) the received hash values with the data sets stored in the client, thus revealing information on which private data sets and stored both in the client and in said server, the unique and respective portion is identical, when said computer program product is executed on a client computer.