GB2444341A - Distributed network messenger system with SPAM filtering, encryption, digital signing and digital contract generation - Google Patents

Abstract

Disclosed is a system for message (e.g. email) delivery across a peer-to-peer network. The system has the property of non-repudiation, to prevent spam. The messages are also encrypted to provide confidentiality, and may remain in encrypted form when stored in buffers during transit. An initial step in the security procedure requires the user to enter a non-public ID, which is used to generate a public-private key pair. The user also has a public ID which is equivalent to an e-mail address in conventional systems. When a user wishes to communicate with another node a handshake procedure may be carried out. This involves sending a signed message to the other node, and can be regarded as a form of SPAM filtering. Also disclosed is a system for signing digital contracts to subject subsequent "conversations" to the terms of the contract. According to another aspect of the invention a user is only granted a public ID if he/she has a sufficient trust ranking.

Description

STATEMENT OF INVENTION:

12 This present invention relates to secure and non refutable 13 messengering. Unlike today's systems such as email and instant 14 messenger this system is fully distributed. Today's systems have many weaknesses such as centralised authentication, poorly maintained and 16 quite complex mail servers. This system seeks to remove this issue by 17 removing the cause, centralisation. Added to this, this present invention 18 introduces another comp'etely new concept, contracted non refutable 19 electronic conversations. The system will allow the selection of existing contracts or allow the user to input his own and then request signatories 21 from all involved in the conversation, allowing a legally protected (in 22 many countries) conversation to take place. This conversation could be 23 a selling, purchasing or merely business deal or indeed any other issue 24 requiring legal protection.

Another important aspect of this system is that the login details are not 26 from this system per say, the system uses anonymously logged in 27 clients who can create a key pair and ID for the messenger. This means 28 any potential theft of ID is made extremely difficult

BACKGROUND:

29 AUTHENTICATION Authentication servers are for user and data transaction authentication 31 e.g. JP200531 1545 which describe a system wherein the application of 32 a digital seal' to electronic documents conforms to the Electronic 33 Signature Act. This is simUar to the case of signing paper documents 34 but uses the application of an electronic signature through an electronic seal authentication system. The system includes: client computers, to 36 each of which a graphics tablet is connected; an electronic seal 37 authentication server and a PKl authentication server, plus the 38 electronic seal authentication server. US2004254894 discloses an 39 automated system for the confirmed efficient authentication of an anonymous subscriber's profile data in this case.

41 JP2005339247 describes a server based one time ID system and uses 42 a portable terminal. US2006136317 discloses bank drop down boxes 43 and suggests stronger protection by not transmitting any passwords or 44 IDs. Patent US2006126848 discloses a server centric and deals with a one time password or authentication phrase and is not for use on a 46 distributed network. Patent US2002194484 discloses a distributed 47 network where all chunks are not individually verified and where the 48 manifest is only re-computed after updates to files and hashes are 49 applied and are for validation only.

SELF-AUTHENTICATION

51 This is mostly used in biometric (W02006069158). System for 52 generating a patch file from an old version of data which consists of a 53 series of elements and a new version of data which also consists of a 54 series of elements US20061 36514). Authentication servers (therefore not a distributed networking principle as per this invention) are 56 commonly used (JP2006107316, US2005273603, EPI 548979).

57 However, server and client exchange valid certificates can be used 58 (US2004255037). Instead of server, uses of information exchange 59 system (semantic information) by participant for authentication can be used (JP2004355358), again this semantic information is stored and 61 referenced unlike this present invention.

62 Concepts of identity-based cryptography and threshold secret sharing 63 provides for a distributed key management and authentication. Without 64 any assumption of pre-fixed trust relationship between nodes, the ad hoc network works in a self-organizing way to provide the key 66 generation and key management service, which effectively solves the 67 problem of single point of failure in the traditional public key 68 infrastructure (PKI)-supported system (US2006023887). Authenticating 69 involves encryption keys for validation (W02005055162) These are validated against known users unlike the present invention. Also, for 71 authentication external housing are used (W02005034009). All of 72 these systems require a lost or (whether distributed or not) record of 73 authorised users and pass phrases or certificates and therefore do not

74 represent prior art.

Ranking, hashing for authentication can be implemented step-by-step 76 and empirical authentication of devices upon digital authentication 77 among a plurality of devices. Each of a plurality of authentication 78 devices can unidirectionally generate a hash value of a low experience 79 rank from a hash value of a high experience rank, and receive a set of high experience rank and hash value in accordance with an experience.

81 In this way, the authentication devices authenticate each other's 82 experience ranks (US2004019788). This is a system of hashing access 83 against known identities and providing a mechanism of effort based 84 access. This present invention does not rely or use such mechanisms.

QuicK ENCIPHERING 86 This is another method for authentication (JP2001 308845). Self- 87 verifying certificate for computer system, uses private and public keys - 88 no chunking but for trusted hardware subsystems (US2002080973) this 89 is a mechanism of self signing certificates for authentication, again useful for effort based computing but not used in this present invention.

91 Other authentication modes are, device for exchanging packets of 92 information (JP2001 186186), open key certificate management data 93 (JP10285156), and certification for authentication (W096139210).

94 Authentication for Peer to Peer system is demonstrated by digital rights management (US2003120928). Digital rights management and CSC 96 (part of that patent s a DRM container) issues which are based on 97 ability to use rather than gaining access to network or resources and

98 therefore not prior art.

99 Known self-healing techniques are divided broadly into two classes.

One is a centralized control system that provides overall rerouting 101 control from the central location of a network. In this approach, the 102 rerouting algorithm and the establishing of alarm collection times 103 become increasingly complex as the number of failed channels 104 increases, and a substantial amount of time will be taken to collect alarm signals and to transfer rerouting information should a large 106 number of channels of a multiplexed transmission system fail. The other 107 is a distributed approach in which the rerouting functions are provided 108 by distributed points of the network. The following papers on distributed 109 rerouting approach have been published: (these are all related to self healing but from a network pathway perspective and therefore are not 111 prior art for this invention which deals with data or data chunks self 112 healing mechanisms.

113 Document 1: W. D. Grover, "The Selfhealing Network", Proceedings of 114 Grobecom 87, November 1987.

Document 2: H. C. Yang and S. Hasegawa, "Fitness: Failure 116 Immunization Technology For Network Service Survivability", 117 Proceedings of Globecom 88, December 1988.

118 Document 3: H. R. Amirazizi, "Controlling Synchronous Networks With 119 Digital Cross-Connect Systems", Proceedings of Globecom 88, December 1988.

121 Document 1 is concerned with a restoration technique for failures in a 122 single transmission system, and Document 2 relates to a "multiple- 123 wave" approach in which route-finding packets are broadcast in multiple 124 wave fashion in search of a maximum bandwidth until alternate routes having the necessary bandwidth are established. One shortcoming of 126 this multiple wave approach is that it takes a long recovery time.

127 Document 3 also relates to fault recovery for single transmission 128 systems and has a disadvantage in that route-finding packets tend to 129 form a loop and hence a delay is likely to be encountered.

SEcuRir, & ENCRYPTION 131 Common email communications of sensitive information is in plain text 132 and is subject to being read by unauthorized code on the senders 133 system, during transit and by unauthorized code on the receiver's 134 system. Where there is a high degree of confidentially required, a combination of hardware and software secures data.

136 A high degree of security to a computer or several computers 137 connected to the internet or a LAN as disclosed in US2002099666.

138 Hardware system is used which consists of a processor module, a 139 redundant non-volatile memory system, such as dual disk drives, and multiple communications interfaces. This type of security system must 141 be unlocked by a pass phrase to access data, and all data is 142 transparently encrypted, stored, archived and available for encrypted 143 backup. A system for maintaining secure communications, file transfer 144 and document signing with PKI, and a system for intrusion monitoring and system integrity checks are provided, logged and selectively 146 alarmed in a tamper-proof, time-certain manner.

147 ENCRYPTION 148 W02005093582 discloses method of encryption where data is secured 149 in the receiving node via private tag for anonymous network browsing.

However, other numerous encryption methods are also avaflable such 151 as (I) implantation of Reed Solomon algorithm (W002052787), which 152 ensures data is coded in parabolic fashion for self-repairing and 153 storage, (ii) storage involves incremental backup (W002052787), (ii) 154 uses stenographic (US2006177094), (iv) use cipher keys (CN1620005), encryption for non text (US2006107048) and US2005108240 discloses 156 user keys and randomly generated leaf node keys. The present 157 invention uses none of these methods of encryption and in particular 158 ensures all chunks are unique and do not point to another for security 159 (an issue with Reed Solomon and N K implementations of parabolic coding) 161 ENCRYPTED DOCUMENT SIGNING 162 W02005060152 discloses a digital watermark representing the one- 163 way hash is embedded in a signature document is used for electronic 164 signing. Mostly encrypted document signing is associated with legal documents, e.g. on-line notary etc. e.g. US2006161781, signature 166 verification (US6381 344). wool 82036 discloses a system and method 167 for signing, storing, and authenticating electronic documents using 168 public key cryptography. The system comprises a document service 169 computer cluster connected to user computers, document owner server computers, and registration computers via a network such as for 171 example, the Internet or the world wide web. W00013368 discloses 172 both the data object and the signature data are encrypted. None of 173 these systems are designed or allow for distributed signing networks 174 unlike the present invention.

US6912660 discloses a method for parallel approval of an electronic 176 document. A document authentication code (DAC 0) is generated, 177 linked to the original document. Subsequent approvals of the document 178 generate a DAC x related to that specific approval. This is not linked to 179 the present invention as it's a document approval system -i.e. one which allows a document to have multiple signatories to authenticate 181 approval, the present invention does not do this at aD.

182 US6098056 discloses a system and method for controlling access 183 rights to and security of digital content in a distributed information 184 system, e.g., Internet. The network includes at least one server coupled to a storage device for storing the limited access digital content 186 encrypted using a random-generated key, known as a Document 187 Encryption Key (DEK). The DEK is further encrypted with the server's 188 public key, using a public/private key pair algorithm and placed in a 189 digital container stored in a storage device and including as a part of the meta-information which is in the container. The client's workstation is 191 coupled to the server (one of the many differences from the present 192 invention) for acquiring the limited access digital content under the 193 authorized condition. A Trusted Information Handler (TIH) is validated 194 by the server after the handler provides a data signature and type of signing algorithm to transaction data descriptive of the purchase 196 agreement between the client and the owner. After the handler has 197 authenticated, the server decrypts the encrypted DEK with its private 198 key and re-encrypts the DEK with the handler's public key ensuring that 199 only the information handler can process the information. The encrypted DEK is further encrypted with the client's public key personalizing the 201 digital content to the client. The client's program decrypts the DEK with 202 his private key and passes it along with the encrypted content to the 203 handler which decrypts the DEK with his private key and proceeds to 204 decrypt the content for displaying to the client.

205 US5436972 discloses a method for preventing inadvertent betrayal by a 206 trustee of escrowed digital secrets. After unique identification data 207 describing a user has been entered into a computer system, the user is 208 asked to select a password to protect the system. US555751 8 discloses 209 a system to open electronic commerce using trusted agents.

210 US5557765 discloses a system and method for data recovery. An 211 encrypting user encrypts a method using a secret storage key (KS) and 212 attaches a Data Recovery Field (DRF), including an Access Rule Index 213 (ARI) and the KS to the encrypted message.

214 US5590199 discloses a system for authenticating and authorizing a 215 user to access services on a heterogeneous computer network. The 216 system includes at least one workstation and one authorization server 217 connected to each other through a network.

218 US2006123227 and W00221409 describe trust based effort measuring 219 techniques to validate signatures without the requirement for a central 220 body or central messaging entity. This is an interesting new concept but 221 not used in the current invention.

Summary of Invention

222 The main embodiments of this invention are as follows: 223 A messaging system which has the functional elements of: 224 1. Provision of Public ID 225 2. Encrypted Communications 226 3. Document Signing 227 4. Contract conversations 228... with the additionally linked functional elements of: 229 1. Share Maps 230 2. Interface with Non-Anonymous Systems 231 3. Provision Key Pairs 232 4. Proven Individual 233 5. Validation of Vote Being Used 234 This present invention relates to secure and non refutable 235 messengering. Unlike today's systems such as email and instant 236 messenger this system is fully distributed. Today's systems have many 237 weaknesses such as centralised authentication, poorly maintained and 238 quite complex mail servers, this system seeks to remove this issue by 239 removing the cause, centralisation. Added to this, this present invention 240 introduces another completely new concept, contracted non refutable 241 electronic conversations. The system will aflow the selection of existing 242 contracts or allow the user to input his own and then request signatories 243 from all involved in the conversation, allowing a legally protected (in 244 many countries) conversation to take place. This conversation could be 245 a selling, purchasing or merely business deal or indeed any other issue 246 requiring legal protection.

247 Another important aspect of this system is that the login details are not 248 from this system per say, the system uses anonymously logged in 249 clients who can create a key pair and ID for the messenger. This means 250 any potential theft of ID is made extremely difficult.

251 A system of secure and non refutable message sending in a distributed 252 and peer to peer network 253 A product for a secure and non refutable message sending in a 254 distributed and peer to peer network 255 A system of secure and non refutable message sending in a distributed 256 and peer to peer network is made up of inter linkage all or some of the 257 following elements: 258 a. contract conversations 259 b. document signing 260 c. encrypted communication 261 d. provision of public ID 262 A system of secure and non refutable message sending in a distributed 263 and peer to peer network is made up of inter linkage all or some of the 264 following elements and sub-elements: 265 a. contract conversations 266 b. document signing 267 i. provision of key pairs 268 c. encrypted communication 269 i. share maps 270 d. provision of public ID 271 i. provision of key pairs 272 ii. proven individuals 273 in. interface with anonymous system 274 A product for a secure and non refutable message sending in a 275 distributed and peer to peer network is made up of inter linkage all or 276 some of the following elements: 277 a. contract conversations 278 b. document signing 279 c. encrypted communication 280 d. provision of public ID 281 A product for a secure and non refutable message sending in a 282 distributed and peer to peer network is made up of inter linkage all or 283 some of the following elements and sub-elements: 284 a. contract conversations 285 b. document signing 286 i. provision of key pairs 287 c. encrypted communication 288 i. share maps 289 d provision of public ID 290 i. provision of key pairs 291 ii. proven individuals 292 iii. interface with anonymous system 293 A product for message sending in a distributed server less environment 294 comprising of;

U

295 a. create a distributed messaging system with secure message 296 buffering; 297 b. create a system of non repudiation between parties; 298 c. create a system of public ID created from private ID and linked by# 299 A method for above product and system of secure and non refutable 300 message sending in a distributed and peer to peer network 301 A method for above product and system of message sending in a 302 distributed server less environment comprising of; 303 a. create a distributed messaging system with secure message 304 buffering; 305 b. create a system of non repudiation between parties; 306 c. create a system of public ID created from private ID and linked by 307 user.

308 From above method further enhance security by passing join requests 309 between users securely over a secure medium and encrypted.

310 The method from above wherein the steps to contact another node is 311 carried out by a signed message indicating the wish to communicate 312 which may comprise of; 313 a. a signed message with private information contained in it or; 314 b. a signed message with previously known information contained in 315 it or; 316 c. a signed message with a previously agreed code.

317 A method from above where a contract may be agreed to and signed 318 prior to a conversation taking place; the conversation is then governed 319 by this contract and may include, but not be limited to; \2.

320 a. Non disclosure agreements

321 b. Full disclosure agreements

322 c. Purchase orders.

323 A method of above where to create a public ID the user has to prove or 324 be spawned as an active participant in another network where 325 resources are stored and utilised to provide an effort based ranking 326 mechanism.

327 A method of above where a user may provide another user with a 328 digitally signed equivalent of a power of attorney' to agree contracts on 329 their behalf.

330 A method of above where messaging activity is ranked by peers and 331 the rank transmitted in conversation requests.

332 A method of above where the Public ID may also indicate a 333 biometrically signed user.

334 A method of above where users may require a ranking or effort score of 335 a certain level before allowing another node to communicate with them.

336 A method of above where this power of attorney' can be instantly 337 withdrawn by originating user without permission or requiring of 338 acceptance by receiver or the power of attorney'.

DESCRIPTION

Detailed Description:

339 (References to IDs used in descriptions of the system's functionality) 340 MID -this is the base ID and is mainly used to store and forget files.

341 Each of these operations will require a signed request. Restoring may 342 simply require a request with an ID attached.

343 PMID -This is the proxy mid which is used to manage the receiving of 344 instructions to the node from any network node such as get! put I forget 345 etc. This is a key pair which is stored on the node -if stolen the key pair 346 can be regenerated simply disabling the thief's stolen PMID -although 347 there's not much can be done with a PMID key pair.

348 CID -Chunk Identifier, this is simply the chunkid.KID message on the 349 net.

350 TMID -This is today's ID a one time ID as opposed to a one time 351 password. This is to further disguise users and also ensure that their MID 352 stays as secret as possible.

353 MPID -The maidsafe.net public ID. This is the ID to which users can add 354 their own name and actual data if required. This is the ID for messenger, 355 sharing, non anonymous voting and any other method that requires we 356 know the user.

357 MAID -this is basically the hash of and actual public key of the MID. this 358 ID is used to identify the user actions such as put I forget / get on the 359 maidsafe.net network. This allows a distributed PKI infrastructure to exist 360 and be automatically checked.

361 KID -Kademlia ID this can be randomly generated or derived from 362 known and preferably anonymous information such as an anonymous 363 public key hash as with the MAID.. In this case we use kademlia as the 364 example overlay network although this can be almost any network 365 environment at all.

366 MSID -maidsafe.net Share ID, an ID and key pair specifically created for 367 each share to allow users to interact with shares using a unique key not 368 related to their MID which should always be anonymous and separate.

Anonymous Authentication Description

369 Anonymous authentication relates to system authentication and, in 370 particular, authentication of users for accessing resources stored on a 371 distributed or peer-to-peer file system. Its aim is to preserve the 372 anonymity of the users and to provide secure and private storage of data 373 and shared resources for users on a distributed system. It is a method of 374 authenticating access to a distributed system comprising the steps of; 375 * Receiving a user identifier; 376 * Retrieving an encrypted validation record identified by the user 377 identifier; 378 * Decrypting the encrypted validation record so as to provide 379 decrypted information; and.

380 * Authenticating access to data in the distributed system using the 381 decrypted information.

382 Receiving, retrieving and authenticating may be performed on a node in 383 the distributed system preferably separate from a node performing the 384 step of decrypting. The method further comprises the step of generating 385 the user identifier using a hash. Therefore, the user identifier may be 386 considered unique (and altered if a collision occurs) and suitable for 387 identifying unique validation records. The step of authenticating access 388 may preferably further comprise the step of digitally signing the user 389 identifier. This provides authentication that can be validated against 390 trusted authorities. The method further comprises the step of using the 391 signed user identifier as a session passport to authenticate a plurality of 392 accesses to the distributed system. This allows persistence of the 393 authentication for an extended session.

394 The step of decrypting preferably comprises decrypting an address in the 395 distributed system of a first chunk of data and the step of authenticating 396 access further comprises the step of determining the existence of the first 397 chunk at the address, or providing the location and names of specific 398 data elements in the network in the form of a data map as previously 399 describe. This efficiently combines the tasks of authentication and 400 starting to retrieve the data from the system. The method preferably 401 further comprises the step of using the content of the first chunk to obtain 402 further chunks from the distributed system. Additionally the decrypted 403 data from the additional chunks may contain a key pair allowing the user 404 at that stage to sign a packet sent to the network to validate them or 405 additionally may preferable self sign their own Ed.

406 Therefore1 there is no need to have a potentially vulnerable record of the 407 file structure persisting in one place on the distributed system, as the 408 user's node constructs its database of file locations after logging onto the 409 system.

410 There is provided a distributed system comprising; 411 * a storage module adapted to store an encrypted validation record; 412 * a client node comprising a decryption module adapted to decrypt an 413 encrypted validation record so as to provide decrypted information; 414 and 415 * a verifying node comprising: 416. a receiving module adapted to receive a user identifier; 417. a retrieving module adapted to retrieve from the storage module an 418 encrypted validation record identified by the user identifier; 419 * a transmitting module adapted to transmit the encrypted validation 420 record to the client node; and 421 * an authentication module adapted to authenticate access to data in 422 the distributed file system using the decrypted information from the 423 client node.

424 The client node is further adapted to generate the user identifier using a 425 hash. The authentication module is further adapted to authenticate 426 access by digitally sign the user identifier. The signed user identifier is 427 used as a session passport to authenticate a plurality of accesses by the 428 client node to the distributed system. The decryption module is further 429 adapted to decrypt an address in the distributed system of a first chunk of 430 data from the validation record and the authentication module is further 431 adapted to authenticate access by determining the existence of the first 432 chunk at the address. The client node is further adapted to use the 433 content of the first chunk to obtain further authentication chunks from the 434 distributed system.

435 There is provided at least one computer program comprising program 436 instructions for causing at least one computer to perform. One computer 437 program is embodied on a recording medium or read-only memory, 438 stored in at least one computer memory, or carried on an electrical 439 carrier signal.

440 Additionally there is a check on the system to ensure the user is login 441 into a valid node (software package). This will preferably include the 442 ability of the system to check validity of the running maidsafe.net 443 software by running content hashing or preferably certificate checking of 444 the node and also the code itself.

Linked elements for ms Messenger (Figure 1 -PT6) 445 The Anonymous Authentication invention consists of 4 key functional 446 elements, with a further 4 functional elements being linked with.

447 The key functional elements are: 448 P17 -Provision of Public ID 449 P18 -Encrypted Communications 450 P19 -Document Signing 451 P20 -Contract Conversations 452 The linked functional elements are: 453 P16 -Share Maps 454 P23 -Interface with Anonymous Systems 455 P13 -Provision of Key Pairs 456 P26 -Proven Individual 457 P28 -Validation of Vote Being Used 459 The ms messenger (P16) itself is made up from linkage of elements, 460 provision of public ID (P17), preferably encrypted communication (P18) 461 and preferably provides document signing (P19) and contract 462 conversations (P20) to provide a system of messaging where identity is 463 validated to prevent spam. The system further uses this identity and key 464 pair to allow digitally validated document signing. In addition, provision of 465 public ID element (P17) is dependent on sub-element provision of key 466 pairs (P 13) and preferably generate sub-element share maps (P26), sub- 467 element proven individual (P26) andsub-element interface with non- 468 anonymous systems (P23). Preferably the encrypted communication 469 element (P 18) generates sub-element share maps (P16) and initiates the 470 validation process (P28) and document signing element (P19) is 471 preferably dependent on sub-element provision of key pairs (P13) Self Authentication Detail (Figure 2) 472 1. A computer program consisting of a user interface and a chunk server (a 473 system to process anonymous chunks of data) should be running, if not 474 they are started when user selects an icon or other means of starting the 475 program.

476 2. A user will input some data known to them such as a userid (random ID) 477 and PIN number in this case. These pieces of information may be 478 concatenated together and hashed to create a unique (which may be 479 confirmed via a search) identifier. In this case this is called the MID 480 (maidsafe.net ID) 481 3. A TMID (Today's MID) is retrieved from the network, the TMID is then 482 calculated as follows: 483 The TMID is a single use or single day ID that is constantly changed.

484 This allows maidsafe.net to calculate the hash based on the user ID pin 485 and another known variable which is calculable. For this variable we use 486 a day variable for now and this is the number of days since epoch 487 (01/01/1 970). This allows for a new ID daily, which assists in maintaining 488 the anonymity of the user. This TMID will create a temporary key pair to 489 sign the database chunks and accept a challenge response from the 490 holder of these db chunks. After retrieval and generation of a new key 491 pair the db is put again in new locations -rendering everything that was 492 contained in the TMID chunk useless. The TMID CANNOT be signed by 493 anyone (therefore hackers can't BAN an unsigned user from retrieving 494 this -in a DOS attack)-it is a special chunk where the data hash does 495 NOT match the name of the chunk (as the name is a random number 496 calculated by hashing other information (i.e. its a hash of the TMID as 497 described below) 498 * take dave as user ID and 1267 as pin.

499 * dave + (pin) 1267 = davel267 Hash of this becomes MID 500 * day variable (say today is 13416 since epoch) 13416 501 * so take pin, and for example add the number in where the pin states 502 i.e. 503 * 613dav41e1267 504 * (6 at beginning is going round pin again) 505 * so this is done by taking 1st pin 1 -so put first day value at position I 506 * then next pin number 2 -so day value 2 at position 2 507 * then next pin number 6 so day value 3 at position 6 508 * then next pin number 7 so day value 4 at position 7 509 * then next pin number is 1 so day value 5 at position 1 (again) 510 * so TMID is hash of 613dav41e1267 and the MID is simply a hash of 511 davel267 512 (This is an example algorithm and many more can be used to enforce 513 further security.) 514 4. From the TMID chunk the map of the users database (or list of files 515 maps) is identified. The database is recovered from the net which 516 includes the data maps for the user and any keys passwords etc.. The 517 database chunks are stored in another location immediately and the old 518 chunks forgotten. This can be done now as the MID key pair is also in 519 the database and can now be used to manipulate user's data.

520 5. The maidsafe.net application can now authenticate itself as acting for 521 this MID and put get or forget data chunks belonging to the user. 2

522 6. The watcher process and Chunk server always have access to the PMID 523 key pair as they are stored on the machine itself, so can start and 524 receive and authenticate anonymous put I get I forget commands.

525 7. A DHT ID is required for a node in a DHT network this may be randomly 526 generated or in fact we can use the hash of the PMID public key to 527 identify the node.

528 8. When the users successfully logged in he can check his authentication 529 validation records exist on the network. These may be as follows: MAID (maidsafe. net anonymous ID) 530 1. This is a data element stored on net and preferably named with the hash 531 of the MID public Key.

532 2. It contains the MID public key + any PMID public keys associated with 533 this user.

534 3. This is digitally signed with the MID private key to prevent forgery.

535 4 Using this mechanism this allows validation of MID signatures by 536 allowing any users access to this data element and checking the 537 signature of it against any challenge response from any node pertaining 538 to be this MID (as only the MID owner has the private key that signs this 539 MID) Any crook could not create the private key to match to the public 540 key to digitally sign so forgery is made impossible given today's 541 computer resources.

542 5. This mechanism also allows a user to add or remove PMIDS (or chunk 543 servers acting on their behalf like a proxy) at will and replace PMID's at 544 any time in case of the PMID machine becoming compromised.

545 Therefore this can be seen as the PMID authentication element.

PMID (Proxy MID) 546 1. This is a data element stored on the network and preferably named with 547 the hash of the PMID public key.

548 2. It contains the PMID public key and the MID ID (i.e. the hash of the MID 549 public key) and is signed by the MID private key (authenticated).

550 3. This allows a machine to act as a repository for anonymous chunks and 551 supply resources to the net for a MID.

552 4. When answering challenge responses any other machine will confirm the 553 PMID by seeking and checking the MIAD for the PMID and making sure 554 the PMID is mentioned in the MAID bit -otherwise the PMID is 555 considered rouge.

556 5. The key pair is stored on the machine itself and may be encoded or 557 encrypted against a password that has to be entered upon start-up 558 (optionally) in the case of a proxy provider who wishes to further 559 enhance PMID security.

560 6. The design allows for recovery from attack and theft of the PMID key pair 561 as the MAID data element can simply remove the PMID ID from the 562 MAID rendering it unauthenticated.

563 Figure 3 illustrates, in schematic form, a peer-to-peer network in 564 accordance with an embodiment of the invention; and 565 Figure 4 illustrates a flow chart of the authentication, in accordance with 566 a preferred embodiment of the present invention.

567 With reference to Figure 3, a peer-to-peer network 2 is shown with nodes 568 4 to 12 connected by a communication network 14. The nodes may be 569 Personal Computers (PCs) or any other device that can perform the 570 processing, communication and/or storage operations required to 571 operate the invention. The file system will typically have many more 572 nodes of all types than shown in Figure 3 and a PC may act as one or 573 many types of node described herein. Data nodes 4 and 6 store chunks 574 16 of files in the distributed system. The validation record node 8 has a 575 storage module 18 for storing encrypted validation records identified by a 576 user identifier.

577 The client node 10 has a module 20 for input and generation of user 578 identifiers. It also has a decryption module 22 for decrypting an encrypted 579 validation record so as to provide decrypted information, a database or 580 data map of chunk locations 24 and storage 26 for retrieved chunks and 581 files assembled from the retrieved chunks.

582 The verifying node 12 has a receiving module 28 for receiving a user 583 identifier from the client node. The retrieving module 30 is configured to 584 retrieve from the data node an encrypted validation record identified by 585 the user identifier. Alternatively, in the preferred embodiment, the 586 validation record node 8 is the same node as the verifying node 12, i.e. 587 the storage module 18 is part of the verifying node 12 (not as shown in 588 Figure 3). The transmitting module 32 sends the encrypted validation 589 record to the client node. The authentication module 34 authenticates 590 access to chunks of data distributed across the data nodes using the 591 decrypted information.

592 With reference to Figure 4, a more detailed flow of the operation of the 593 present invention is shown laid out on the diagram with the steps being 594 performed at the User's PC (client node) on the left 40, those of the 595 verifying PC (node) in the centre 42 and those of the data PC (node) on 596 the right 44.

597 A login box is presented 46 that requires the user's name or other detail 598 Preferably email address (the same one used in the client node software 599 installation and registration process) or simply name (i.e. nickname) and 600 the user's unique number, preferably PIN number. If the user is a main 601 user' then some details may already be stored on the PC. If the user is a 602 visitor, then the login box appears.

603 A content hashed number such as SHA (Secure Hash Algorithm), 604 Preferably 160 bits in length, is created 48 from these two items of data.

605 This hash' is now known as the User ID Key' (MID), which at this point is 606 classed as unverified' within the system. This is stored on the network as 607 the MAID and is simply the hash of the public key containing an 608 unencrypted version of the public key for later validation by any other 609 node. This obviates the requirement for a validation authority 610 The software on the user's PC then combines this MID with a standard 611 hello' code element 50, to create 52 a hello.packet'. This hello.packet is 612 then transmitted with a timed validity on the Internet.

613 The hello.packet will be picked up by the first node (for this description, 614 now called the verifying node') that recognises 54 the User ID Key 615 element of the hello.packet as matching a stored, encrypted validation 616 record file 56 that it has in its storage area. A login attempt monitoring 617 system ensures a maximum of three responses. Upon to many attempts, 618 the verifying PC creates a black list' for transmission to peers.

619 Optionally, an alert is returned to the user if a black list' entry is found 620 and the user may be asked to proceed or perform a virus check.

621 The verifying node then returns this encrypted vafldation record file to the 622 user via the Internet. The user's pass phrase 58 is requested by a dialog 623 box 60, which then will allow decryption of this validation record file.

624 When the validation record file is decrypted 62, the first data chunk 625 details, including a decrypted address', are extracted 64 and the user PC 626 sends back a request 66 to the verifying node for it to initiate a query for 627 the first file-chunk ID' at the decrypted address' that it has extracted 628 from the decrypted validation record file, or preferably the data map of 629 the database chunks to recreate the database and provide access to the 630 key pair associated with this MID.

631 The verifying node then acts as a relay node' and initiates a notify only' 632 query for this file-chunk ID' at the decrypted address'.

633 Given that some other node (for this embodiment, called the data node') 634 has recognised 68 this request and has sent back a valid notification 635 only' message 70 that a file-chunk ID' corresponding to the request sent 636 by the verifying node does indeed exist, the verifying node then digitally 637 signs 72 the initial User ID Key, which is then sent back to the user.

638 On reception by the user 74, this verified User ID Key is used as the 639 user's session passport. The user's PC proceeds to construct 76 the 640 database of the file system as backed up by the user onto the network.

641 This database describes the location of all chunks that make up the 642 user's file system. Preferably the ID Key will contain irrefutable evidence 643 such as a public/private key pair to allow signing onto the network as 644 authorised users, preferably this is a case of self signing his or her own 645 ID -in which case the ID Key is decrypted and user is valid -self 646 validating.

647 Further details of the embodiment will now be described. A proxy-648 controlled' handshake routine is employed through an encrypted point-to- 649 point channel, to ensure only authorised access by the legal owner to the 650 system, then to the user's file storage database, then to the files therein.

651 The handshaking check is initiated from the PC that a user logs on to 652 (the User PC'), by generating the unverified encrypted hash' known as 653 the User ID Key', this preferably being created from the user's 654 information preferably email address and their PIN number. This hash' 655 is transmitted as a hello packet' on the Internet, to be picked up by any 656 system that recognises the User ID as being associated with specific 657 data that it holds. This PC then becomes the verifying PC' and will 658 initially act as the User PC's gateway' into the system during the 659 authentication process. The encrypted item of data held by the verifying 660 PC will temporarily be used as a validation record', it being directly 661 associated with the user's identity and holding the specific address of a 662 number of data chunks belonging to the user and which are located 663 elsewhere in the peer-to-peer distributed file system. This validation 664 record' is returned to the User PC for decryption, with the expectation 665 that only the legal user can supply the specific information that will allow 666 its accurate decryption.

667 Preferably this data may be a signed response being given back to the 668 validating node which is possible as the Id chunk when decrypted 669 (preferably symmetrically) contains the users public and private keys 670 allowing non refutable signing of data packets.

671 Preferably after successful decryption of the TMID packet (as described 672 above) the machine will now have access to the data map of the 673 database and public/private key pair allowing unfettered access to the 674 system.

675 It should be noted that in this embodiment, preferably no communication 676 is carried out via any nodes without an encrypted channel such as TLS 677 (Transport Layer Security) or SSL (Secure Sockets Layer) being set up 678 first. A peer talks to another peer via an encrypted channel and the other 679 peer (proxy) requests the information (e.g. for some space to save 680 information on or for the retrieval of a file). An encrypted link is formed 681 between all peers at each end of communications and also through the 682 proxy during the authentication process. This effectively bans snoopers 683 from detecting who is talking to whom and also what is being sent or 684 retrieved. The initial handshake for self authentication is also over an 685 encrypted link 686 Secure connection is provided via certificate passing nodes, in a manner 687 that does not require intervention, with each node being validated by 688 another, where any invalid event or data, for whatever reason (fraud 689 detection, snooping from node or any invalid algorithms that catch the 690 node) will invalidate the chain created by the node. This is all transparent 691 to the user.

692 Further modifications and improvements may be added without departing 693 from the scope of the invention herein described.

694 Figure 5 illustrates a flow chart of data assurance event sequence in 695 accordance with first embodiment of this invention 696 Figure 6 illustrates a flow chart of file chunking event sequence in 697 accordance with second embodiment of this invention 698 Figure 7 illustrates a schematic diagram of file chunking example 699 Figure 8 illustrates a flow chart of self healing event sequence 700 Figure 9 illustrates a flow chart of peer ranking event sequence 701 Figure 10 illustrates a flow chart of duplicate removal event sequence 2') 702 With reference to Figure 5, guaranteed accessibility to user data by data 703 assurance is demonstrated by flow chart. The data is copied to at least 704 three disparate locations at step (10). The disparate locations store data 705 with an appendix pointing to the other two locations by step (20) and is 706 renamed with hash of contents. Preferably this action is managed by 707 another node i.e. super node acting as an intermediary by step (30).

708 Each local copy at user's PC is checked for validity by integrity test by 709 step (40) and in addition validity checks by integrity test are made that 710 the other 2 copies are also still ok by step (50).

711 Any single node failure initiates a replacement copy of equivalent leaf 712 node being made in another disparate location by step (60) and the other 713 remaining copies are updated to reflect this change to reflect the newly 714 added replacement leaf node by step (70).

715 The steps of storing and retrieving are carried out via other network 716 nodes to mask the initiator (30) 717 The method further comprises the step of renaming aH files with a hash 718 of their contents.

719 Therefore, each file can be checked for validity or tampering by running a 720 content hashing algorithm such as (for example) MD5 or an SHA variant, 721 the result of this being compared with the name of the file.

722 With reference to Figure 6, provides a methodology to manageable sized 723 data elements and to enable a complimentary data structure for and 724 compression and encryption and the step is to file chunking. By user's 725 pre-selection the nominated data elements (files are passed to chunking 726 process. Each data element (file) is split into small chunks by step (80) 727 and the data chunks are encrypted by step (90) to provide security for the 728 data. The data chunks are stored locally at step (100) ready for network 729 transfer of copies. Only the person or the group, to whom the overall data 730 belongs, will know the location of these (100) or the other related but 731 dissimilar chunks of data. All operations are conducted within the user's 732 local system. No data is presented externally.

733 Each of the above chunks does not contain location information for any 734 other dissimilar chunks. This provides for, security of data content, a 735 basis for integrity checking and redundancy.

736 The method further comprises the step of only allowing the person (or 737 group) to whom the data belongs, to have access to it, preferably via a 738 shared encryption technique. This allows persistence of data.

739 The checking of data or chunks of data between machines is carried out 740 via any presence type protocol such as a distributed hash table network.

741 On the occasion when all data chunks have been relocated (i.e. the user 742 has not logged on for a while,) a redirection record is created and stored 743 in the super node network, (a three copy process -similar to data) 744 therefore when a user requests a check, the redirection record is given to 745 the user to update their database.

746 This efficiently a'lows data resilience in cases where network churn is a 747 problem as in peer to peer or distributed networks.

748 With reference to Figure 7 which illustrates flow chart example of file 749 chunking. User's normal file has 5Mb document, which is chunked into 750 smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks 751 may be compressed and encrypted by using Pass phrase. Next step is to 752 individually hash chunks and given hashes as names. Then database 753 record as a file is made from names of hashed chunks brought together 754 e.g. in empty version of original file (Cl IIIIiiI/IIIIIIII,tl,t2,t3: 755 C2/IIIIIIII/I!/I/f,tl,t2,t3 etc), this file is then sent to transmission queue in 756 storage space allocated to client application.

757 With reference to Figure 8 provides a self healing event sequence 758 methodology. Self healing is required to guarantee availability of accurate 759 data. As data or chunks become invalid by failing integrity test by step 760 (110). The location of failing data chunks is assessed as unreliable and 761 further data from the leaf node is ignored from that location by step (120).

762 A Good Copy' from the known good' data chunk is recreated in a new 763 and equivalent leaf node. Data or chunks are recreated in a new and 764 safer location by step (130). The leaf node with failing data chunks is 765 marked as unreliable and the data therein as dirty' by step (140). Peer 766 leaf nodes become aware of this unreliable leaf node and add its location 767 to watch list by step (150). All operations conducted within the user's 768 local system. No data is presented externally.

769 Therefore, the introduction of viruses, worms etc. will be prevented and 770 faulty machines/ equipment identified automatically.

771 The network will use SSL or TLS type encryption to prevent unauthorised 772 access or snooping.

773 With reference to Figure 9, Peer Ranking id required to ensure consistent 774 response and performance for the level of guaranteed interaction 775 recorded for the user. For Peer Ranking each node (leaf node) monitors 776 its own peer node's resources and availability in a scaleable manner, 777 each leaf node is constantly monitored.

778 Each data store (whether a network service, physical drive etc.) is 779 monitored for availability. A qualified availability ranking is appended to 780 the (leaf) storage node address by consensus of a monitoring super node 781 group by step (160). A ranking figure will be appended by step (160) and 782 signed by the supply of a key from the monitoring super node; this would 3D 783 preferably be agreed by more super nodes to establish a consensus for 784 altering the ranking of the node. The new rank will preferably be 785 appended to the node address or by a similar mechanism to allow the 786 node to be managed preferably in terms of what is stored there and how 787 many copies there has to be of the data for it to be seen as perpetual.

788 Each piece of data is checked via a content hashing mechanism for data 789 integrity, which is carried out by the storage node itself by step (170) or 790 by its partner nodes via super nodes by step (180) or by instigating node 791 via super nodes by step (190) by retrieval and running the hashing 792 algorithm against that piece of data. The data checking cycle repeats 793 itself.

794 As a peer (whether an instigating node or a partner peer (i.e. one that 795 has same chunk)) checks the data, the super node querying the storage 796 peer will respond with the result of the integrity check and update this 797 status on the storage peer. The instigating node or partner peer will 798 decide to forget this data and will replicate it in a more suitable location.

799 If data fails the integrity check the node itself will be marked as dirty' by 800 step (200) and dirty' status appended to leaf node address to mark it as 801 requiring further checks on the integrity of the data it holds by step (210).

802 Additional checks are carried out on data stored on the leaf node marked 803 as dirty' by step (220). If pre-determined percentage of data found to be 804 dirty' node is removed from the network except for message traffic by 805 step (230). A certain percentage of dirty data being established may 806 conclude that this node is compromised or otherwise damaged and the 807 network would be informed of this. At that point the node will be removed 808 from the network except for the purpose of sending it warning messages 809 by step (230). 3'

810 This allows either having data stored on nodes of equivalent availability 811 and efficiency or dictating the number of copies of data required to 812 maintain reliability.

813 Further modifications and improvements may be added without departing 814 from the scope of the invention herein described.

815 With reference to Figure 10, duplicate data is removed to maximise the 816 efficient use of the disk space. Prior to the initiation of the data backup 817 process by step (240), internally generated content hash may be 818 checked for a match against hashes stored on the internet by step (250) 819 or a list of previously backed up data (250). This will allow only one 820 backed up copy of data to be kept. This reduces the network wide 821 requirement to backup data which has the exact same contents.

822 Notification of shared key existence is passed back to instigating node by 823 step (260) to access authority check requested, which has to pass for 824 signed result is to be passed back to storage node. The storage node 825 passes shared key and database back to instigating node by step (270) 826 Such data is backed up via a shared key which after proof of the file 827 existing (260) on the instigating node, the shared key (270) is shared with 828 this instigating node. The location of the data is then passed to the node 829 for later retrieval if required.

830 This maintains copyright as people can only backup what they prove to 831 have on their systems and not publicly share copyright infringed data 832 openly on the network.

833 This data may be marked as protected or not protected by step (280) 834 which has check carried out for protected or non-protected data content.

835 The protected data ignores sharing process. 3'L

ms_messenger (Figure 1 -PT6 and Figure 11) 836 1. A non public ID preferably one which is used in some other autonomous 837 system is used as a sign in mechanism and creates a Public ID key pair.

838 2. The user selects or creates their public ID by entering a name that can 839 easily be remembered (such as a nickname) the network is checked for a 840 data element existing with a hash of this and if not there, this name is 841 allowed. Otherwise the user is asked to choose again.

842 3. This ID called the MPID (maidsafe.net public ID) can be passed freely 843 between friends or printed on business cards etc. as an email address is 844 today.

845 4. To initiate communications a user enters the nickname of the person he 846 is trying to communicate with along with perhaps a short statement (like a 847 prearranged pin or other challenge). The receiver agrees or otherwise to 848 this request, disagreeing means a negative score starts to build with 849 initiator. This score may last for hours, days or even months depending 850 on regularity of refusals. A high score will accompany any communication 851 request messages. Users may set a limit on how many refusals a user 852 has prior to being automatically ignored.

853 5. All messages now transmitted are done so encrypted with the receiving 854 party's public key, making messages less refutable.

855 6. These messages may go through a proxy system or additional nodes to 856 mask the location of each user.

857 7. This system also allows document signing (digital signatures) and 858 interestingly, contract conversations. This is where a contract is signed 859 and shared between the users. Preferably this signed contract is equally 860 available to all in a signed (non changeable manner) and retrievable by 861 all. Therefore a distributed environment suits this method. These 862 contracts may be NDAs Tenders, Purchase Orders etc. 863 8. This may in some cases require individuals to prove their identity and this 864 can take many forms from dealing with drivers licenses to utility bills 865 being signed off in person or by other electronic methods such as 866 inputting passport numbers, driving license numbers etc. 867 9. If the recipient is on line then messages are sent straight to them for 868 decoding.

869 10. If the recipient is not on line, messages are require to be buffered as 870 required with email today.

871 11. Unlike today's email though, this is a distributed system with no servers to 872 buffer to. In maidsafe.net messages are stored on the net encrypted with 873 the receiver's public key. Buffer nodes may be known trusted nodes or 874 not.

875 12. Messages will look like receivers ID. message I message 2 or simply 876 be appended to the users MPID chunk, in both cases messages are877 signed by the sender. This allows messages to be buffered in cases 878 where the user is offline. When the user comes on line he will check his 879 ID chunk and look for appended messages as above ID.messagel etc. 880 which is MPID.<message 1 data>.<message 2 data> etc 881 This system allows the ability for automatic system messages to be sent, 882 i.e... in the case of sharing the share, data maps can exist on everyone's 883 database and never be transmitted or stored in the open. File locks and 884 changes to the maps can automatically be routed between users using 885 the messenger system as described above. This is due to the distributed 886 nature of maidsafe. net and is a great, positive differentiator from other 887 messenger systems. These system commands will be strictly limited for 3' 888 security reasons and will initially be used to send alerts from trusted 889 nodes and updates to share information by other shares of a private file 890 share (whether they are speaking with them or not).

Provision of Public ID (Figure 1 -P17) 891 According to a related aspect of this invention, a public and Private 892 key pair is created for a network where preferably the user is 893 anonymously logged on, and preferably has a changeable pseudo 894 random private Id which is only used for transmission and retrieval of ID 895 blocks giving access to that network.

896 Preferably this public private key pair will be associated with a public ID.

897 This ID will be transmittable in a relatively harmless way using almost 898 any method including in the open (email, ftp, www etc.) but preferably in 899 an encrypted form. Preferably this ID should be simple enough to 900 remember such as a phone number type length. Preferably this ID will be 901 long enough however, to cope with the entire world's population and 902 more, therefore it would be preferably approx 11 characters long.

903 This ID can be printed on business cards or stationary like a phone 904 number or email address and cannot be linked to the users private ID by 905 external sources. However the user's own private information makes this 906 link by storing the data in the ID bit the user retrieves when logging in to 907 the network or via another equally valid method of secure network 908 authentication.

909 This ID can then be used in data or resource sharing with others in a 910 more open manner than with the private id. This keeps the private ID 911 private and allows much improved inter-node or inter- person 912 communications.

Encrypted Communications (Figure 1 -P18) 913 According to a related aspect of this invention, the communications 914 between nodes should be both private and validated. This is preferably 915 irrefutable but there should be options for refutable communications if 916 required. For irrefutable communications the user logs on to the network 917 and retrieves their key pair and ID. This is then used to start 918 communications. Preferably the user's system will seek another node to 919 transmit and receive from randomly -this adds to the masking of the 920 user's private ID as the private ID is not used in any handshake with 921 network resources apart from logging in to the network.

922 As part of the initial handshake between users, a key may be passed.

923 Preferably this is a code passed between users over another 924 communications mechanism in a form such as a pin number known only 925 to the users involved or it may be as simple as appending the user's 926 name and other info to a communication request packet such as exists in 927 some instant messaging clients today -i.e. David wants to communicate 928 with you allow / deny I block.

929 Unlike many communications systems today, this is carried out on a 930 distributed server-less network. This however provides the problem of 931 what to do when users are off line. Today messages are either, stopped 932 or stored on a server, and in many cases not encrypted or secured. This 933 invention allows users to have messages securely buffered whilst off line.

934 This is preferably achieved by the node creating a unique identifier for 935 only this session and passing that ID to all known nodes in the user's 936 address book. Users on-line get this immediately, users off-line have this 937 buffered to their last known random ID. This ensures that the ability to 938 snoop on a user's messages is significantly reduced as there is no 939 identifier to people outside the address book as to the name of the 940 random ID bit the messages are stored to. The random ID bit is 941 preferably used as the first part of the identified buffer file name and 942 when more messages are stored then another file is saved with the 943 random Id and a number appended to it representing the next sequential 944 available number. Therefore a user will log on and retrieve the messages 945 sequentially. This allows buffered secured and distributed messaging to 946 exist.

Document Signing (Figure 1 -P19) 947 According to a related aspect of this invention, a by-product of 948 securing communications between nodes using asymmetric encryption is 949 as previously stated, introducing a non-refutable link. This allows for not 950 only messages between nodes to be non-refutable but also for 951 documents signed in the same manner as messages to be non refutable.

952 Today somebody can easily steal a user's password or purposely attack 953 users as they are not anonymous; this invention provides a great deal of 954 anonymity and backs this up with access to resources.

955 Documents may be signed and passed as legally enforceable between 956 parties as a contract in many countries.

Contract Conversations (Figure 1 -P20) 957 According to a related aspect of this invention, a conversation or 958 topic can be requested under various contracted conditions. The system 959 may have a non disclosure agreement as an example and both parties 960 digitally sign this agreement automatically on acceptance of a contract 961 conversation. In this case a non disclosure conversation. This will 962 preferably speed up and protect commercial entities entering into 963 agreements or where merely investigating a relationship. Preferably other 964 conditions can be applied here such as preferably full disclosure 965 conversations, Purchase order conversations, contract signing 966 conversations etc. This is all carried out via a system preferably having 967 ready made enforceable contracts for automatic signing. These contracts 968 may preferably be country or legal domain specific and will require to be 969 enforceable under the law of the countries where the conversation is 970 happening. This will require the users to preferably automatically use a 971 combination of geographic lP status and by selecting which is their home 972 country and where are they are at that time located and having that 973 conversation.

974 Preferably only the discussion thread is under this contract, allowing any 975 party to halt the contract but not the contents of the thread which is under 976 contract.

977 Preferably there can also be a very clear intent statement for a 978 conversation that both parties agree to. This statement will form the basis 979 of a contract in the event of any debate. The clearer the intent statement 980 is; the better for enforceability. These conversations are potentially not 981 enforceable but should lead to simplifying any resolution required at a 982 later date. Preferably this can be added together with an actual contract 983 conversation such as a non disclosure agreement to form a pack of 984 contracts per conversation. Contract conversations will be clearly 985 identified as such with copies of the contracts easily viewable by both 986 parties at any time, these contracts will preferably be data maps and be 987 very small in terms of storage space required.

Claims (4)

1. 988 1. A system of secure and non refutable message sending in a server less 989 distributed and peer to peer network is made up of inter linkage and 990 combinations of all or some of the following elements: 991 a. contract conversations 992 b. document signing 993 c. encrypted communication 994 d. provision of public ID 995
2. 2. A system of claim 1 of secure and non refutable message sending in a 996 server less distributed and peer to peer network is made up of inter 997 linkage and combinations of all or some of the following elements and 998 sub-elements: 999 a. contract conversations 1000 b. document signing 1001 I) provision of key pairs 1002 C. encrypted communication 1003 i) share maps 1004 d. provision of public ID 1005 i) provision of key pairs 1006 ii) proven individuals 1007 iii) interface with anonymous system 1008
3. 3. A product for a secure and non refutable message sending in a server 1009 less distributed and peer to peer network is made up of inter linkage and 1010 combinations of all or some of the following elements: 1011 a. contract conversations 1012 b. document signing 1013 C. encrypted communication 1014 d. provision of public ID 1015
4. 4. A product of claim 3 for a secure and non refutable message sending in 1016 a server less distributed and peer to peer network is made up of inter 1017 linkage and combinations of all or some of the following elements and 1018 sub-elements: 1019 a. contract conversations 1020 b. document signing 1021 i) provision of key pairs 1022 c. encrypted communication 1023 i) share maps 1024 d. provision of public ID 1025 i) provision of key pairs 1026 ii) proven individuals 1027 iii) interface with anonymous system 1028 5 A product of claims 1-4 for message sending in a distributed server less 1029 environment comprising of; 1030 a. create a distributed messaging system with secure message 1031 buffering; 1032 b. create a system of non repudiation between parties; 1033 c. create a system of public ID created from private ID and linked by 1034 user 1035 6. A method of claim 5, which further enhances security by passing join 1036 requests between users securely over a secure medium and encrypted; 1037 7. A method of claims 5 and 6, wherein the steps to contact another node is 1038 carried out by a signed message indicating the wish to communicate 1039 which may comprise of; 1040 a. a signed message with private information contained in it or; 1041 b. a signed message with previously known information contained in it 1042 or; 1043 c. a signed message with a previously agreed code; 1044 8. A method of claims 5 and 6, where a contract may be agreed to and 1045 signed prior to a conversation taking place; the conversation is then 1046 governed by this contract and may include, but not be limited to;

   1047 a. Non disclosure agreements

   1048 b. Full disclosure agreements

   1049 c. Purchase orders.

   1050 9. A method of claims 5 and 6, which is to create a public ID the user has to 1051 prove or be spawned as an active participant in another network where 1052 resources are stored and utilised to provide an effort based ranking 1053 mechanism; 1054 10. A method of claim 8 where a user may provide another user with a 1055 digitally signed equivalent of a power of attorney' to agree contracts on 1056 their behalf; 1057 11. A method of claim 7 where messaging activity is ranked by peers and the 1058 rank transmitted in conversation requests; 1059 12. A method of claim 9 where the Public ID may also indicate a 1060 biometrically signed user; 1061 13. A method of claim 11 where users may require a ranking or effort score 1062 of a certain level before allowing another node to communicate with 1063 them; 4ç\ 1064 14. A method of claim 14 where this power of attorney' can be instantly 1065 withdrawn by originating user without permission or requiring of 1066 acceptance by receiver or the power of attorney;