Call signs

The present invention relates to a relatively short "callsign" for identifying a user to a computer network.

Keys and cryptographic identifications (IDs) play an important role in many applications that require user verification, such as computer systems. In an embodiment of a peer-to-peer computer system, user identification (ID) is to the system administrator who verifies that the user has the right to access the network when the ID is presented electronically, such as by email. It can be used as a certificate (verifier). Separately, the ID can also be communicated by voice or writing.

<p> Previously, IDs were presented manually, either using business cards or verbally. An ID is usually a long sequence of binary numbers that is not easily remembered. The identity can be secured using an encryption process. However, protected IDs are usually longer and difficult to circulate easily. Therefore, the user also gives up the usability when protecting the ID by encryption.</p><p> The following is a brief description of the disclosure so that the reader can get a basic understanding. This "disclosure of the invention" is not a broad overview of the disclosure and does not identify or delineate the key / significant elements of the invention. As a prelude to the detailed description described below, it is solely intended to describe some of the concepts disclosed herein in a simplified form.</p>

<p> The present invention provides a relatively short "callsign" for identifying a user to a computer network. This network may be a peer-to-peer network in which the individual computers in the network need to be more secure than in other networks. The callsign incorporates information about the person presenting the callsign asking them to join the network. Callsigns are short and easy to remember, but traditional IDs are usually long and hard to remember. The callsign also incorporates a pre-computed "salt" value, which outputs a fixed-length result that can be easily converted to a callsign containing letters and numbers by hashing itself and personal information. Information other than personal information can be incorporated into hashing depending on the application.</p><p> Those skilled in the art will appreciate that it is desirable to have a short, easily memorable ID that is secured by ciphertext. This type of callsign is always short enough to be remembered, but it can still provide sufficient security and enhance the convenience of peer-to-peer or other networks.</p><p> Many of the accompanying features of the present invention will be apparent as they can be easily understood by reference to the following detailed description discussed with respect to the accompanying drawings.</p><p> The following description will best be understood by reference to the various parts of the drawing that form part of this disclosure and are briefly described below.</p>

The detailed description described below with respect to the accompanying drawings is intended as a description of this embodiment of the invention and is not intended to represent the only embodiment in which the invention can be constructed or utilized. This description defines the sequence of steps that make up and operate the invention with respect to the functions of the invention and the embodiments illustrated. However, the same or equivalent function and order can be achieved by different embodiments that are also intended to be included within the spirit and scope of the invention.

The present invention has been described and exemplified herein as being implemented within a peer-to-peer computer network system, but the described system is presented as an example and is intended to be limiting. It is not presented. Those skilled in the art will appreciate that the present invention is suitable for applications with a wide variety of different types of computer systems.

FIG. 1 is a diagram showing standard secure user identification used to access peer-to-peer networks or equivalent network examples. A peer-to-peer computer network is a network of computers that can function without a server computer, and the responsibility for its security rests with each peer computer in the network. As is well known, the identifier 101 used to identify and validate a user's access rights is usually quite long. Such binary numbers are typically 160 bits long (102), which is equal to a 40-digit hexadecimal number. Another embodiment of identifier 101 is a PNRP name that contains two components, a number represented by 40 hexadecimal numbers and a string of arbitrary length. Such identification cannot be easily communicated except by the machine.

Many computer networks may require the generation of peer names commonly used in the "peer-to-peer" name resolution process. As currently implemented, peer-to-peer name resolution protocols (PNRPs) typically use short peer names that are user-friendly (tend not to have sufficient security features) or are user-friendly (usually). Is constrained to use long peer names that contain long binary columns (with a higher level of security). Those skilled in the art will appreciate that shortened identifiers can be applied to any type of computer network, or to a system where a secure, shortened identification tool is desired.

Long peer names can usually be secured by applying an encryption process. However, such long names are usually not user-friendly. Long names are usually difficult to remember and enter to gain access to a computer network. That is, the latest technology usually forces users to choose between convenience and security. Within a peer-to-peer network, it is desirable to provide a means of identifying a computer using short, easy-to-remember identifiers in a secure manner.

(First embodiment of callsign with the number of I.0 specified and how to generate them) FIG. 2 is a diagram showing a representation of the abbreviated callsign identifier 202 generated by the first embodiment of the method of generating a callsign. In particular, in this embodiment, the "number field of 0" in the call sign is used. By using the systems and methods for generating secure callsigns for peer-to-peer identification (callsigns) as described herein, peer-to-peer networks (P2P), and known to those of skill in the art. Generate an easy-to-remember security code or callsign 202 that can be used for other equivalent network applications. In particular, the specific information used in constructing the callsign, and the cryptographic features applied, allow the callsign to be used in a variety of applications. For example, one embodiment of the callsigns and methods of generating those callsigns can be applied to the Peer-to-Peer Name Resolution Protocol (PNRP). Other applications can include, but are not limited to.

It solves the challenge of securely communicating a user's identity by generating callsigns that are commonly used for peer-to-peer identification. Security is achieved by using a secure process to configure short callsigns that are easy for the user to remember and enter. Strong protection can be provided by the encryption process against such callsigns. For example, the peer-to-peer identification callsign 202, such as "ZA4-3Y-4W-ZF4", is short and secure. Remembering such a callsign is only a little more difficult than remembering a Social Security number.

The illustrated callsign example 202 contains 10 alphanumeric characters. Those skilled in the art will appreciate that callsigns containing more or fewer characters can be generated. Each of the 10 callsign characters represents 5 binary bits 203. These segments are part of a longer binary number that is divided into five bit segments. Those skilled in the art will appreciate that they can be used in equivalent embodiments to represent binary numbers with a length greater than or less than 5 bits.

The first digit of the callsign digit is the letter "Z", as you can see in this example. In this embodiment, the first digit is defined to convey the number of 0s used in decoding the callsign. Here, the letter Z is defined to represent the decimal number 31, which is the 5-bit binary number 11111. Those skilled in the art may differ in the arrangement of digits that identify the number of 0s and the number of 0s in the callsign in equivalent embodiments of the invention. Similarly, in the embodiment, any bit pattern or character can be selected instead of "Z".

The remaining nine alphanumeric characters in this callsign represent the rest of the binary number. These digits are designated as ("L"). In this embodiment, L is 45 bits in length. The binary number L is taken from the result of the encryption process used to encrypt the user identification. The remaining L bits in the 2nd to 10th digits are divided into 5-bit segments that are mapped to the remaining 9 alphanumeric characters. Those skilled in the art will appreciate that mapping of binary numbers to alphanumeric characters can be performed by table lookup, formulas, or other equivalent methods known to those of skill in the art. Those skilled in the art will also appreciate that the ordering of the 10 letters may differ even in equivalent embodiments.

After decrypting the number of 0s and the number L from the call sign, encryption processing is executed for the binary number to recreate the user's ID. Once the user's identity is established, the person holding the callsign can be granted access to the network and other privileges.

(<u style="single">Modifier</u>Generation of the first embodiment of the callsign from) It is assumed that the entity to be named owns the traditionally generated public / private key pair K / P and personalization information string, or digital ID, X. The personalization information string can consist of the natural attributes of the entity to be named. For example, the personalization information string can include a combination of common names, company names, city names, and email addresses. The public key K constructed as before can be represented by a binary character string, and the personalization information character string can be represented by a text character string.

Figure 3 shows the structure of the call sign. The first step in the callsign generation process is that if S is hashed with K310 and X309 through an encrypted one-way function ("H (x)") 308 (307), the result starts with a large number of 0s,<u style="single">Hash value</u>("H") 301,<u style="single">"Salt"</u>To find the value S. Subsequent steps to generate the callsign require a certain number of 0s.<u style="single">salt value</u>In finding, you can try a large number of values over a given time interval and produce the desired number of 0s.<u style="single">salt value</u>Is retained.<u style="single">salt value</u>This allows the callsign to pass the verification procedure when the user presents a callsign for authentication.

Those skilled in the art will appreciate that certain bit patterns can be used instead of leading zeros. For example, in other embodiments, the preceding 1 or the minimum number of "0110" groups may be used. When generating a callsign, we want some of the calls to match a given pattern, but the rest of the bits that make up the callsign and tend to have no pattern are the callsigns. Make up the remaining digits of. Apart from that, the prescribed pattern is<u style="single">Hash value</u>It is also possible to get it from a quadratic function instead of the hash function used to generate.

Hashing is a process often used in cryptographic processes that output fixed-size results by applying a mathematical function called a hashing algorithm to any amount of data. The hash functions used in these embodiments are of a type known to those of skill in the art. Standard hashing algorithms include MD2, MD4, MD5, and SHA-1.

The hash function used in these embodiments can be characterized as a one-way cryptographic hash function. As those skilled in the art will understand, a one-way hash function usually has multiple unique properties, but it is easy to calculate a fixed-length hash value or result from an arbitrary-length message input. Yes, given a fixed-length hash value, it is difficult to calculate an arbitrary-length message, and given an arbitrary-length message input, find other messages that generate the same fixed-length hash value. Because it is difficult.

<u style="single">salt value</u>And other strings<u style="single">Hash H</u>301 starts with a large number of 0s (or other equivalent predefined bit patterns) on the MSB side of the number generated by that hash. Those skilled in the art may place multiple 0s (or other equivalent predefined bit patterns) in LSB digits or other positions in other equivalent embodiments, or of the hashes or other functions described. You will understand that it is possible to use the ordinal characteristic as an indicator.<u style="single">salt value</u>And final<u style="single">hash</u>Is found through the iteration of a one-way hash function that evaluates to different salt values. A salt value that produces a hash with a large number of leading 0s is<u style="single">hash</u>Is held as. The trial is repeated until a certain time T elapses. One of ordinary skill in the art would have to spend time in multiples of T to find the same number of 0s and match them against 40 or 45 bits in a plurality of embodiments of the invention. You will understand that it tries to find 0 during a fixed time "T".<u style="single">salt value</u>An embodiment of the search process for finding a can be written as: Initialize the number of 0s to find: Z = 0 During time T, do the following: Select a new salt value V HV = Calculate one-way hash (K, X, V) Calculate Y, the number of leading 0s in the HV If (Y&gt; Z) S = V, H = HV, Z = Y At the end of the specified time T,<u style="single">salt value</u>S and<u style="single">H</u>Is found.

<u style="single">Hash H</u>Is defined as a hash of K, X, and S through a strong one-way function with respect to cryptography.<u style="single">hash</u>= H = H (K, X, S)

Is a binary number<u style="single">Hash H</u>A logical callsign is created from.<u style="single">hash</u>301 consists of a predetermined number of bits (M). M is<u style="single">hash</u>Includes a leading 0 (Z) 302 of, and a preselected number of bits (L) 303 of the distinguished hash value H immediately following the last leading 0 (or LSB of leading 0).

After the number of 0s is determined, the next step is to include it in the callsign content<u style="single">Hash H</u>Is to determine the number of remaining bits from. (<u style="single">salt value</u>The parameters T and L (used in finding) are selected with security and scaling considerations in mind. The above process has two parameters: the period T during which the trial is executed and the number of selected bits L. These parameters are determined by taking into account scaling to a given number of entries, making spoofing attacks by hackers difficult, and ensuring future security and continued use of callsigns. To continue using it in the future, it is usually a matter of considering Moore's Law so that increasing the speed of the computer does not negate the non-counterfeiting of callsigns. A further consideration when choosing these parameters is to resist "catalog" attacks from hackers.

(Code-coding of the number of 0s in the first embodiment) Once the number of 0s is known, we must also find a way to code that number in the callsign. Keep the total number of bits small enough to be encoded into a short digital or alphanumeric string to generate a short callsign with sufficient security. The total number of bits to be encoded is the sum of the number L and the number of bits required to encode the number Z of 0s. Usually, the number Z is less than 128 and can be coded in 7 bits.

In other embodiments, instead of coding the actual number of null bits, it is possible to code the number of null octets that use 4 bits, or the number of null "4-bit nibbles" that use 5 bits. is there. The modified process for finding a sufficient number of nibbles is:

Initialize the number of 0s to find: Z = 0 During time T, do the following: Select a new salt value V HV = Calculate one-way hash (K, X, V) Calculate Y, the number of leading nibbles in the HV If (Y&gt; Z) S = V, H = HV, Z = Y For example, 24 leading 0s can be obtained in less than a minute by this method, typically on a conventional PC with a 1GHz CPU.

As shown below, the number L, which is the group of bits following the leading 0 that makes up the callsign, will rarely be less than 40 bits. The practical range for the number Z of leading 0s is between 24 and 88. Values between 24 and 87 can be encoded using the following formula: Z = 24 + R

In this formula, R is a number that varies between 0 and 63. Equivalent to this, the following formula can also be used: Z = 24 + 2^*P

P is a number in the range 0-31 that encodes the number of pairs of 0. Numbers between 0 and 31 are fairly practical as they can be encoded as a single alphanumeric character. The modified process of finding a sufficient number of 0s that can be encoded into a single alphanumeric character is:

Initialize the number of pairs of 0 to find: Z = 0 Repeat the following: Select a new salt value V HV = Calculate one-way hash (K, X, V) Calculate the number of leading pairs in the HV, Y If (Y&gt; Z) S = V, H = HV, P = Z Until Z is greater than 24 and time T elapses Set Z = Z-12 The next trade-off is the choice of value L and time T. The selection will be described later.

Callsigns suitable for casual exchange are obtained by using digital or alphanumeric coding of logical callsigns, including 0 number Z coding and L selected bit coding. The Z + L bit 304 that makes up the call sign can be divided into several 5-bit segments. Each 5-bit segment is represented by alphanumeric characters. The alphanumeric characters are then assembled into callsign 305. And finally, one or more separators are added to form the final callsign 306. It is also possible to adopt a callsign shortening rule such as deleting the preceding "Q".

Figure 4 shows the process of determining the callsign. At step 401<u style="single">Modifier</u>Is configured. At step 402<u style="single">salt value</u>Can be found. At step 403<u style="single">salt (S)</u>, Personalization information string (X), and public key (K) are hashed to M bits. In step 404, the number of leading 0s is found in the hash. In step 405, the number of leading zeros (Z) is extracted from the hash. At step 406, the number of bits (L) is extracted from the hash and put into the callsign. And finally, in step 407, the alphanumeric representation of the Z and L bits is found and the callsign is formed.

(Callsign verification procedure) When a third party receives the callsign, it tells the intended owner of the callsign the public key K, the personalization information string X, and<u style="single">saltS</u>Verify the association between the code sign, public key, and personalization information string by requesting the value of. Third parties use certificates from K, X, and S<u style="single">hash</u>To calculate. It then verifies that the number of leading 0s matches the value Z represented in the callsign, verifies that the value Z is greater than or equal to a given minimum value, and is encoded in the callsign. Verify that the L bits in the hash match the corresponding bits in the hash value. As an additional precaution, Verifier "visually" checks whether the personalization information string X corresponds to the expected natural value.

As already mentioned, the parameters T and L are chosen with security and scaling in mind. The above process has two parameters: the period T during which the trial is executed and the number of selected bits L. These parameters need to be scaled to a given number of entries, not to be easily spoofed, and to be used in the future, that is, Moore's. It depends on the need to endure the law. Further consideration is resistance to "catalog" attacks.

(Selection of L and T considering possible spoofing attacks) The process of linking a public key to a short signature must be wary of spoofing attacks, where an attacker finds another public key with the same signature.

A common defense is to rely on the difficulty of generating a public key. If the signature is a public key and some fixed hash of text, and the signature is L-bit long, the attacker would have to generate 2 ^ L public keys to find a match. Those skilled in the art will appreciate that the task of generating a public key involves finding two long prime numbers, which is a very expensive operation. However, only an incompetent attacker would try to find a matching key using standard key generation software. Instead, an attacker could use a process like this: Get the first prime number. Add a prime number to the list. Repeat the following: Get a new prime number P. Repeat for each prime Q in the list: N = P^*Calculate Q (simple multiplication) Calculate the public key K associated with N Calculate hash (K, personalization information) If (hash matches target) // Our win RETURN (P, Q) END if END For If list size &lt;maximum size Add P to the list End list End repeat

In this process, for the largest list of size M, the prime number calculation only occurs once for every M loops on average. By choosing a large M, the attacker effectively minimizes the effect of prime generation on the execution time of the core loop, but is ultimately dominated by the cost of the hash function. Relying on the complexity of public key generation is not an efficient defense.

To find a hash containing Z leading 0s, the generator must perform about 2 ^ (Z) operations, so to find the corresponding hash, the attacker has about 2 ^ ( You will have to perform Z + L) operations. By choosing sufficiently large values for Z and L, it is guaranteed that spoofing for callsigns is difficult, and no assumptions can be made regarding the generation of prime numbers.

Another well-known defense is to increase the cost of a hash function by requiring, for example, performing a standard hash several times in order to obtain what can be called a "power hash of N". Regardless of cryptographic considerations, the symmetric cost increase of hash functions is a drawback and applies to both callsign generation and its validation. This is not a desirable property. An asymmetrical setup, which can require a lot of computation to generate to thwart spoofing attacks, may be desired, but validation is very fast to avoid overloading the reader.

The callsign process requires the generator to make multiple attempts to find a sufficient number of leading zeros. This may require a long generation time, but it does not affect the validation time and is only slightly slower than a simple hash comparison.

(Selection of L and T in consideration of future use and Moore's Law) The evolution of computing power over time is also usually taken into account when assessing the cryptographic strength of hashing algorithms. According to Moore's Law, the computing power available for a given cost doubles approximately every one and a half years and quadruples every three years. This means that if everything else is the same, the amount of computing power available to an attacker doubles every year and a half. In other words, an attack that currently takes a million years will be completed within a year in 30 years from now. Code that seems unbreakable at the moment can be very easily attacked in the future, unless it's hard enough or "makes it usable in the future."

To protect the callsign from future attacks, choose the first number of 0s to follow Moore's Law. By doing this, Moore's Law helps secure callsigns. Instead of over-dimensioning the code so that a long callsign is generated, choose the first number of zeros according to Moore's Law. The code currently in use may contain a relatively small number of zeros, but the code used within a few years will contain an increasing number of leading zeros.

If new code is generated on a new machine, spend the same amount of time in the generation process three years from now to find the hash with two zeros added. Those skilled in the art will appreciate that the cost of generation is proportional to 2 ^ (Z) and the cost of attack is proportional to 2 ^ (Z + L). If you try to spend a fixed amount of time on generation, the attacker will have to spend 2 ^ L times that time to launch the attack. In other words, the attack is as difficult as it is now, 30 years from now. For example, if the generation period T is set to 1 minute and the length L is set to 40 bits, the generation of spoofed values will require nearly 2 million years of computation on current machines for the next 30 years. Similarly generated callsigns require 2 million years of computation on similar machines for spoofing.

However, this argument applies only if the callsign is used only for a short period of time. To break the 40-bit callsign generated over a minute in 2003, do two million years of calculations using multiple computers available in 2003, or one year, such 200. It is necessary to use 10,000 computers in parallel. Breaking the 40-bit callsign generated in 2033 over a minute would still require two million years of calculations using multiple computers available that year. But 2033 computers can break the 2003 callsign in just two years.

As a result, callsigns become obsolete in some way. Callsigns generated in a particular year will probably not be used for quite some years. The overall resilience of a callsign depends on the time spent generating it and the number of bits L. The longer the generation process, the more resilient it is, and every time the generation time T is doubled, it is protected from repeating Moore's Law. In yet other embodiments, a truly strong sign can be formed by running the generation process over an extended period of time.

In yet other embodiments, reasonable protection is achieved by associating an expiration date with the callsign. This is especially attractive when the callsign is used as a bootstrap mechanism to find the other party's actual public key. After the public key is found, you can use the full information instead of the compressed information shown in the callsign. Complete information is fairly less vulnerable to obsolescence.

(Selection of L and T considering the possibility of natural collision) Even in the absence of an attack, the short code has a problem, which is "natural" when two users happen to choose a combination of keys, personalization information strings, and salt values that have the same callsign. The possibility of a collision.

The bit length L used in the callsign is limited to keep the callsign short, but the population of computer users (P) can be very large. For example, using a method known to those skilled in the art, assigning at least one callsign to each computer user in the population of P = 10 ^ 10 so that the probability of collision is less than 50%, the length. L will exceed 67 bits. If the probability of collision must be less than 1%, then L must be greater than 73 bits.

Such a large bit string would be encoded with a 15 alphanumeric callsign. Such a length exceeds the practical length of the callsign. In other words, completely eliminating the possibility of collision means that the personalization information string has a unique token such as an email address embedded in it, and this unique token is securely transferred along with the callsign. It is practical only when it is used.

Since the callsign length is constrained and collisions occur, a method of detecting collisions is adopted. Conflicts are resolved using callsign resolution. In the event of a conflict, the reader gets multiple versions of the public key, personalization information string, and salt value associated with the callsign, all of which pass the first-level validation process. The reader selects the "correct" or "expected" version based on the personalization information string. The conflict resolution process can be repeated by performing the following steps or equivalent steps. 1) Start searching for callsigns. 2) Extract the public key, personalization information string, and salt value associated with the callsign. 3) If there is no such available entry, the search ends as a failure. 4) Perform verification using a one-way function. If it fails, repeat step 2. 5) If the personalization information string matches the expected value, the search succeeds and ends. 6) If the personalization information strings do not match, repeat step 2.

If the resolution process is efficient, the key should be long enough to maintain the frequency of conflicts that are compatible with the conflict resolution mechanism. For example, it is inefficient to endlessly examine a long list of personalization information strings. Those skilled in the art will understand that collisions are fairly rare, and if 2 ^ L is sufficiently larger than P, that is, if L&gt; log2 P, then only a few matching entries will be involved. Will.

(Quantification when selecting L and T) The first embodiment of the callsign consists of a set of alphanumeric characters. Each character is a coded version of 5-bit information. For length considerations, the first embodiment of the callsign must not be alphanumeric characters longer than 10 characters. One of the ten characters is the coded number Z of zeros. The remaining 9 characters are L bits encoded, and when 5 bits are used for each character, L is 45 bits. Other embodiments of L = 35, 40, or 45-bit callsigns are also possible. For the first embodiment, upon reaching L of 45 bits, the above criteria are quantified using methods known to those of skill in the art. The value of L can be assigned a quantifiable metric to know which of the values is accessible, as well as the time T that must be spent searching for 0. There is.

The previous section described spoofing attacks, catalog attacks, natural collisions, and computational power that increases over the years, but is summarized by the following criteria: The total Z + L must be large enough to prevent spoofing. The number Z of 0 corresponds to the calculation time T. Product T^*2 ^ L must be large enough to prevent spoofing, even when considering repeated Moore's Law several times. The personalization information string must be unique enough to thwart catalog attacks. The length L must be long enough so that name collisions are rare, given a portable population size.

(Quantification in the selection of L and T considering spoofing attacks) Figure 5 is a table showing the choice of length L and time T based on disabling spoofing attacks. This table shows how many years of calculation is required to break the sign, the number of bits (35, 40, or 45) and the calculation time T (15, 60, 240, 960, or 3840 seconds) spent. It is shown as a function of. In this table, double underlined and bold values are less than 100,000 years. The calculations required to break the key can be easily distributed across the computer network. Those skilled in the art will understand that previously a network of 100,000 computers could break the crypto challenge. To make the callsign resist cracking into such a network for at least a year, a 35-bit L is not the best choice unless the search for 0 lasts for at least 4 minutes.

Values greater than 10,000,000 years are italics with a single underline, and these values require 100 years of computation on a network of 100,000 current computers. As you can see from the table, a 45-bit L is generally safe. Using a 45-bit L in combination with a search time (T) for 0s of 16 minutes or more gives a callsign that may remain valid for 10 years.

(Quantification in selection of L and T considering catalog attack) Figure 6 is a table showing the vulnerability of callsigns to the various callsigns formed from the L bits and the distinct salt values calculated in T seconds. Short codes such as callsigns can be subject to "catalog" attacks, a variant of spoofing attacks. In this attack, an attacker or a group of attackers generate a number of callsign "solutions" and store them in a database, or catalog. Each solution links specific values of public key and callsign known to the attacker. Those skilled in the art will appreciate that this table also shows the size of the catalog that can be built in a year by a network of 100,000 computers. The "Vulnerability" column indicates the number of occurrences of the cataloged name that must exist in the network for the catalog to contain at least one valid callsign.

Those skilled in the art will appreciate that catalog attacks can only be applied to popular personalization information strings. If the personalization information string contained only the user's first and last name, the catalog attack would have little effect.

In other embodiments, the inclusion of additional tokens in the personalization information string can reduce the frequency of occurrence of common names and enhance the security of callsigns. For example, city and country names can be added to the personalization information string. Catalog attacks can then only target users with the same additional tokens in their personalization information. For example, a user who has the same name and surname and lives in the same city. Those skilled in the art will appreciate that these users form a relatively small population. Those skilled in the art will appreciate that there are rarely more than hundreds of such users in the city. From this table, it can be seen that the combination of the bit length L of 45 bits and the duration T of 4 minutes (240 seconds) ensures sufficient security in this application.

In yet another embodiment, the personalization information string contains a unique token, such as an email address, and if this token is securely passed as part of a callsign, the catalog attack will be nullified. .. Successful catalog attacks like this are as difficult as spoofing attacks.

(Avoiding unpleasant identifiers) Generating callsigns is a matter of luck, which can lead to highly undesirable callsigns such as "IAM-SO-DUMB". Because it is randomly selected, it can even result in callsigns that contain words that are clearly offensive, such as forbidden four-letter words.

The surest way to eliminate these occurrences is to present the suggested callsign to the user and have the user accept the suggested value or request another value. Designing the calculation as 16 sequential steps makes it easier to quickly regenerate other callsigns. If the callsign is rejected, in other embodiments it is sufficient to use only 1/16 of the time required for a completely new calculation and repeat the very last step of the procedure. If the design in which the callsign is derived by the final hash step is maintained, yet another embodiment introduces the final salt value at that stage so that a random number is simply chosen to derive a new callsign. It is possible.

In yet another embodiment, protection against unwanted callsigns is embedded by adding a step to include a list of "undesirable keywords" in the generation process. Include keywords Such protection makes the code itself somewhat offensive. However, in other embodiments, alphanumeric encoding of binary numbers becomes a problem. Therefore, it is possible to include a coded binary value in the program instead of the actual keyword. These are existing but unreadable formats.

(II. Second embodiment of callsigns where the requested number of 0s is set by the certificate and how to generate them) In the first embodiment, there is some room for improvement. It may not be necessary to encode the number of 0s in the callsign, so consider a shorter callsign, or a callsign that contains the equally long but greater number of significant bits L. Also, undesired results may occur with alphanumeric encoding. This can result in "readable" strings containing inadvertent and offensive words. The callsign generation process must ensure that such words are avoided.

(Code-coding of the number of 0s in the second embodiment) Coding the number of zeros in the first embodiment is a compromise. It is assumed that the number of 0s is always greater than 24, less than 98, and sufficient accuracy can be obtained by coding the number of pairs rather than the number of 0s.

More basicly, in coding the number of zeros in a callsign, the owner of the callsign must determine the number of zeros required. In the first embodiment,<u style="single">salt</u>It is assumed that the time spent searching for is fixed, and that the number of 0s found within that time represents "according to Moore's Law" and represents the average capacity of the computer for the year. However, because the time limit is fixed, there is a dependency between the ability of the computer used to generate the callsign and the strength of that callsign. In the second embodiment, it is assumed that the required number of 0s is determined by the recipient of the callsign.

In this embodiment, the check is encoded in the verification code. The callsign recipient is the public key K, identifier X, and<u style="single">saltS</u>And then verify that the number Z of 0s in the hash is greater than the minimum value, which is a function of the year Y and the number of significant bits L. Z&gt; Z0-L + (Y-2003) / X

In this formula, the number Z0 is set to represent the key length that was considered strong enough in 2003. The factor X indicates the number of years it takes for the average computer to double its power. For a practical implementation, setting the value of X to 1.5 and the value of Z0 to 62 according to Moore's Law gives the following formula: Z&gt; 62-L + (Y-2003) /1.5

In this formula, the number 62 is a value calculated assuming that the calculation for 100,000 years is a sufficient obstacle. In fact, the "bar" can be quite dependent on the background circumstances in which the callsign is used. For financial purposes, it may require a larger value, for example 66 (1,000,000 years). For military use, the conditions are even more severe.

(III. Alphanumeric coding of callsign passages to ASCII) Figures 7 and 8 show the alphanumeric coding of the callsign. When creating callsigns, it is desirable to choose the letters and / or numbers of the callsigns that are easy to distinguish from each other and are not prone to transcription errors. Alphanumeric representation is assigned to the peer identifier. The coding examples selected in these embodiments do not use the numbers 0 and 1 or the letters O and I in the resulting callsign. Those skilled in the art will appreciate that these letters are not used because they tend to be confused with each other, but that they can be used in other embodiments. Those skilled in the art will also appreciate that in other embodiments, other characters can be eliminated or added. Those skilled in the art will appreciate that other embodiments of the invention are not practically limited to Roman letters and Arabic numerals. Those skilled in the art will further understand that all numbers or letters can be used as long as the desired number of symbols can be produced. In the embodiment, by removing unnecessary letters, 8 numbers and 24 letters are left, and 32 symbols are obtained as shown in the figure.

As mentioned above, when generating a callsign, this process assigns a number from 0 to 31 for each letter chosen for use within the callsign, resulting in 32 available symbols. Output. When the callsign is read by the computer, each character in the callsign is assigned a number in computer memory. When the callsign is output from the computer, the numbers or letters that make up the callsign that are output to the user are assigned to each number that makes up the callsign in the computer. The combination of characters that make up the call sign is selected by the call sign generation procedure. The callsign verification procedure then checks its validity.

(IV. Callsign applied within Peer Name Resolution Protocol (PNRP)) FIG. 9 is a block diagram of a peer-to-peer network that utilizes one embodiment of a peer-to-peer callsign. Peer-to-peer network technology enables real-time communication over one or more distributed networks. Peer-to-peer networking is a serverless technology. In a peer-to-peer network, individual PCs can exchange data, share resources, identify other users, communicate, and collaborate in real time without using Internet services. PCs typically include application software that enables peer-to-peer communication when the PC is coupled to a peer-to-peer network. In this type of network, each peer computer is responsible for maintaining its own security. Therefore, validating authorized users and resolving conflicting addresses is a task that is performed in a somewhat different way than server-based networks.

Connecting to and then joining a peer group is a common task in peer networks that utilize security measures in identifying users. To join a group, the peer computer receives an invitation from the owner of the peer group. To receive an invitation from the group owner, the temporary group member must first hand over the peer name and public key identification material to the group owner. This information is passed using email, file sharing, XML, and so on. The group owner then issues an invitation to the temporary group members.

When the temporary group member receives the information, it uses the invitation information to connect to the group. To connect to a group, the temporary group member uses the PNRP and group ID to resolve the group member's address and connect to the peer network through that group member.

Mutual authentication between a temporary group member and a current group member is usually performed through a trusted web. After mutual authentication, the temporary group member becomes a new group member with a single neighbor. A neighbor is a computer from a peer network that accepts connections and has been authenticated.

In particular, with respect to connections to peer-to-peer computer networks, peer-to-peer networks include infrastructure networking software that provides a set of networking application program interfaces (APIs) for networking. These peer-to-peer applications may be involved in collaborative communications, content delivery, and so on. Peer-to-peer infrastructure API software can include components such as peer name resolution protocol, multipoint communication, distributed data management, secure peer identities, and secure peer-to-peer groups.

Peer-to-peer name resolution protocol (PNRP) allows peers in a peer-to-peer network to resolve "peer names" without the need for a server that would normally be needed in a server-based network. .. PNRP allows peer computers to identify other computers in the network, the peers. The Peer Name Resolution Protocol includes an application program interface (API) that enables peer-to-peer resolution of names to multiple endpoints or multiple nodes in a conflictable network.

The Peer Name Resolution Protocol (PNRP) API is a name-IP resolution protocol that allows a group of participating peers to interact with each other by allowing computer nodes to find each other in a peer-to-peer network. Tasks typically provided within a peer-to-peer network include registering and unregistering peer names, resolving peer names, and enumerating groups of peers. As those skilled in the art will understand, peer name resolution involves finding peer names that do not conflict with each other. In addition to finding names that do not conflict with each other, it is desirable that the names found are sufficiently secure and that the user can remember their peer names.

A peer name is a stable name that can identify a computer, user, group, or service. The peer name usually includes a classifier that is just a string and the authority to indicate whether the peer is secure. As those skilled in the art will understand, secure peer names typically use a secure hash algorithm (SHA-1) or MD5 algorithm to derive a 128-bit PNRP identifier and obtain the public key K. Hashing to classifier C can provide secure transmission of peer names. In a third embodiment, C includes identifiers X, salt S, and identification of the hashing algorithm.

Cryptographic keys are a mechanism known to those skilled in the art for security measures within network communications. Cryptographic keys are commonly used in peer-to-peer environments to grant access and verify source identification. Cryptographic keys allow the person who owns the key to access the data associated with the key or create a digital signature for the key owner. Public key algorithms usually include a pair of public and private keys, represented as K / P. The private key must be kept secret and secure as it can be used as an identifier to the recipient of the message. The public key can be freely distributed and others can freely decrypt the message. The public key of a key pair is often distributed with a digital certificate. If one key in a key pair is used to encrypt a message, the other key in that pair is used to decrypt the message.

These keys tend to be long, usually at least 256 hexadecimal numbers. Therefore, it can be cumbersome to hand over them, especially the public key. Instant messaging or email can be used, but is vulnerable to tampering and key verification is desirable. It is also desirable that the key verification process include verification that the person receiving the key is the person the sender intends to send the key to.

(IV. Third embodiment of callsign as applied to peer-to-peer name resolution protocols) The Peer-to-Peer Name Resolution Protocol (PNRP) allows peers to resolve peer names without service. The PNRP peer name first consists of two fields: the SHA-1 hash of the public key, "authority," and the Unicode text string, "qualifier." PNRP derives a 128-bit PNRP-ID from these two fields using a cryptographic hashing function such as: PNRP-ID = hash (authority, hash (qualifier))

This third embodiment enhances PNRP with a "callsign". To generate the PNRP callsign, the user<u style="single">Modifier</u>Is generated. Authority,<u style="single">salt value</u>,and<u style="single">Modifier</u>As a result of the combination of, a large number of 0-based PNRP-IDs are obtained. The call sign is derived from this PNRP-ID. The new PNRP API allows users to enumerate PNRP entries that match callsigns and then obtain the associated permissions and qualifiers.

(<u style="single">PNRP</u>Qualifier)<u style="single">Modifier</u>Is a personalization information string, a quadratic hash function identifier, and separated by the delimiters "//" and "/".<u style="single">salt value</u>Formed from. Those skilled in the art will appreciate that the content of the personalization information string may vary depending on the application in which the callsign is used. For example, the PNRP callsign embodiment uses a unique personalization information string, but other applications may require a different personalization string.

Those skilled in the art will appreciate that these strings are separated by delimiters or other equivalent methods known to those of skill in the art. Those skilled in the art will also understand that the order of the strings and the delimiters used may be different.

The hash function used is also<u style="single">Modifier</u>Included in, separated by a delimiter. As those skilled in the art will understand, the hash function may be of a type known to those skilled in the art that has sufficient security measures. For example, there is a SHA-1 hash function or its equivalent.

salt is selected during the callsign generation process. The salt is selected by performing a secondary hash of the peer name, so that the hashed result starts with a sufficient number of 0s. The salt itself consists of ASCII alphanumeric characters. The formal syntax is as follows:<u style="single">Modifier</u>= &lt;Personalization&gt; // &lt;hash function&gt; / &lt;salt&gt;<u style="single">Modifier</u>An example of is shown below.

Qualifier: JonSmith &lt;jsmith@yuhoo.com&gt; // SHA1 / A5E5F3Z4YWZTRF0TW9RTQ salt is chosen so that the secondary hashes of permissions and modifiers start with a large number of 0s.

(Generation of third embodiment of callsign) The purpose of the callsign generation procedure is to allow the peer name and associated callsign to pass the validation procedure.<u style="single">Modifier</u>Is to find. This is the proper "<u style="single">salt</u>The secondary hash of the peer name starts with the appropriate number of 0s, as it involves finding.

As shown in the validation section, the appropriate number of 0s will change over time. formula Z&gt; 17+ (Y-2003) /1.5 Is used for those purposes.

For generation purposes, the value Y should not be set in the current year, but rather in the last year of the period in which the callsign is valid. By default, this is set to the current year +10.

The generation proceeds as follows. 1) Initialize the value of the PNRP name privilege according to the PNRP, using the canonical form of this privilege as expected in the validation procedure. 2) Initialize the value of personalization information X according to the user name. 3) By default SHA-1, select a valid quadratic hash function and note the corresponding identifier I. 4) Select the appropriate number Z of 0s. 5) Repeat the following until the number N is greater than or equal to the number Z: Select Salt S. b. Authority-based peer names and tentative<u style="single">Modifier</u>Based on X, I, and S. c. Compute the hash of the peer name according to function I. d. Measure the number of zeros (N) in this hash. 6) Calculate the PNRP identifier associated with the peer name. 7) Configure the callsign based on the most significant 45 bits of the PNRP identifier. 8) Verify that the callsign does not contain offensive words, and if so, repeat step 5.

Step 5 is expected to last about 15 seconds on a modern computer.

The final step in the generation function is to check for any offensive words from a random collection of letters in the callsign. This can be implemented by asking the user if they accept the proposed callsign.

(Verification of the callsign generated in the third embodiment) The callsign verification procedure compares the peer identifier with the callsign and verifies that the secondary hash contains a sufficient number of leading zeros. By verifying the number of leading 0s, it becomes difficult for a third party to spoof the callsign. In the first approximation, the cryptographic strength of the callsign is equal to the strength of a symmetric key of length Z + 45. The value of Z may change over time. As Moore's Law predicts that computers will become more and more powerful, the length requirement for Z tends to increase. Assuming that Moore's Law holds for the foreseeable future, the value for the leading 0 number Z can be thought of as a function of the current year Y. Z&gt; 17+ (Y-2003) /1.5

For those skilled in the art, the value 17 used in the above inequality corresponds to the trade-off relationship between the selected security and the calculation, and the tighter the conditions, the larger the selected value can be. You will understand that there is sex.

The quadratic hash function used to validate the callsign can change over time. The current implementation uses the hash function SHA1, known to those of skill in the art. In other embodiments, the list of acceptable hash functions can be kept in computer memory for use. In particular, it is expected that the development of hash functions will continue to improve security. Embodiments of the present invention can accommodate the development of new hash functions by defining future use when new hash functions appear.

The verification proceeds as follows. 1) Calculate the PNRP identifier associated with the peer name. 2) Compare the most significant 45 bits of the PNRP identifier with the 45 bits encoded in the callsign. 3) If the 45 bits do not match, the verification fails. Four)<u style="single">salt</u>Extract the identifier of the quadratic hash function from. 5) If the hash function identifier is missing, the certificate does not accept it, or it is not recognized as a valid value, the validation fails. 6) Compute the hash of the canonicalized version of the entire peer name with the specified quadratic hash function. 7) Measure the number of leading 0s in the resulting hash. If the number of 0s is less than the target value Z, the validation fails. 8) Verify that the identification string is a reasonable description of the person or entity specified by the callsign, otherwise the verification fails. 9) If steps 1-8 pass, the verification is successful.

To get a "normalized version" of a peer name, the authoritative part of the peer name, which usually consists of hexadecimal numbers, is always encoded with only numbers and uppercase letters A, B, C, D, E, and F. To do so. Note that step 8 usually involves human interaction.

(Retrieving PNRP record from callsign) In some cases, it may be useful to retrieve the PNRP record associated with the callsign, and therefore the associated peer name. To do so, retrieve all PNRP records whose PNRP identifier starts with the same 45 bits as the callsign, retrieve the corresponding peer name, remove the peer name that cannot pass steps 1-7 of the validation procedure, and step 8 of the validation procedure. Use to leave only names that match the expected ID.

The embodiments of the present invention claiming exclusive rights or privileges are defined in the claims.

<figref num="1">FIG. 5 shows a standard secure user identification used to access a peer-to-peer computer network.</figref><figref num="2">It is a figure which shows the representation of the shortened callsign identifier generated by the 1st Embodiment of the method of generating a callsign.</figref><figref num="3">It is a figure which shows the structure of a call sign.</figref><figref num="4">It is a flow chart which shows the process of determining a call sign.</figref><figref num="5">A table showing callsign vulnerabilities to various callsigns formed from L bits and distinct salt values calculated in T seconds.</figref><figref num="6">It is a table which shows the contrast between the collision frequency and the size of a group with respect to a bit length L of 45 bits.</figref><figref num="7">It is a figure which shows the alphanumeric character coding of a call sign.</figref><figref num="8">It is a figure which shows the alphanumeric character coding of a call sign.</figref><figref num="9">It is a flow diagram which shows the process of generating a callsign as used in the 3rd Embodiment of a callsign.</figref>

Code description

202 callsign identifier