STRAT ID GIC is the only permanent security solution for identity and payment details to the decryption problem, but our first patent did not protect any of the other data sent and stored. Our patent pending tech covers that problem.
The technology we submitted for patent protection 12/30/2020 provides reciprocal authentication solutions for both simple IOT devices and complex bidirectional devices. (See the post quantum remote control problem.) Reciprocal authentication mathematically proves the identity of the sender, to our server.
It provides temporary protections to all the data STRAT ID GIC sends and stores. (See our version of symmetric encryption).
HIDDIN physically controls all the information on our platform but communally shares ownership with our buyers and their anonymity is critical to the success of the HIDDIN mission.
Making our information available to sellers is how the bills get paid and where most of the rewards we share come from, but the data does not belong to them anymore. Should HIDDIN fail to honor that mission or breach the trust that communal ownership requires the buyer participation binding this venture together would be at risk of unraveling.
We need buyers and sellers that are tired of business as usual, that understand the urgency of this quantum threat, and believe the power of our data belongs to the people.
Join us by sharing just enough of your identity and contact information so we can show you what it is like to go de-identified with our trial communication membership.
STRAT ID GIC and the HIDDIN Marketplace and Communication Platform built with STRAT ID GIC technologies.
STRAT ID GIC and the HIDDIN Marketplace and Communication Platform built with STRAT ID GIC technologies are looking for an army of first adopter buyers and sellers to help us kick the tires on our pre-launch version of these technologies as we roll them out and adapt them to each communication and transaction processing channel and customize them for each industry type.
Buyers we need your feed back on what works and especially on what does not. Sellers we need more than just your feed back we need the help of your accountant. Your accountant can help maintain the balance between your operations limited ability to scale quickly and the HIDDIN Marketplace's digital platforms ability to scale your sales too quickly.
The only thing that might be worse than not having enough sales is selling more than you can afford to bring to market. You will only get one shot at a first impression with a new customer and you want that experience to be one that promotes a long term relationship. That is the kind of relationship we want with you and why we need your help with this pre-launch to get a chance at a good impression with everyone that will come after you.
This pre-launch is not just the introduction of a few new technologies it is part of a much greater effort to help make sure that we the people will finally take control of our identity, contact and marketing information. Then control our data in the future. Right now everyone we have ever done business with has collected identity, contact, and marketing information about us and likely sold it to others. It is never complete, never up to date, neither secure nor very useful. They control it and we the people do not.
De-identification of everyone's marketing, communication and transaction data makes it secure to send and store. It also makes it possible for HIDDIN to reunite marketing communication and transaction data without including any identity, contact or payment information. Sellers can query this data, form marketing campaigns that HIDDIN can then deliver to the correct parties anonymously. Then each buyer decides what if anything happens next. Sellers get the access they need and buyers get the control they have never had and everyone enjoys the efficiency and shares in the rewards HIDDIN provides for cooperating. (See the benefits of the HIDDIN Marketplace)
We need buyers and sellers that are tired of business as usual, that understand the urgency of this quantum threat, and believe the power of our data belongs to the people. Join us by sharing just enough of your identity and contact information so we can show you what it is like to go de-identified with our trial communication membership.
What use is a communication medium if you do not have anyone you want to contact? How are you going to find out what works and does not work if you have no one to use it with?
Everyone that joins our free trial is encouraged to invite at least twelve others with our free trial and they will be able to invite twelve more. Now that you have someone to communicate with get at it! We will add the marketplace as soon as it is built so you can kick it around too.
If we do not take control of our information now with this effort we may never get another chance! It is our data only if we make it ours. Make it happen by signing up at hiddin.net. It is yours for the taking. Take it or others will!
The reasons for not using symmetric encryption for everything are that each reuse of the same symmetric key is revealing and all the key management problems associated with requiring a unique key for everyone you contact.
. For example Sue and BOB would need a unique key to encrypt and then decrypt the transmissions between them and then both Sue and Bob would need unique keys for all the other 998 people they would want to contact and then each of those people would need another 998 unique keys to contact all those same people.
This creates a key management problem and when any key is comprised the parties that share that key must get yet another unique key. Then reusing that same key over time reveals a little about that key each time it is used.
Reciprocal authentication is not just for phone calls and messaging. Our tech was originally designed for simple IOT devices with limited power, WiFi and CPU capabilities that might just need a little more program storage space to adapt to our tech.
IOT devices power up when they have data to report and initiate a WiFi connection to a specific server recipient to synchronize time and then send the results of two simple calculations for the server receiving this information to mathematically prove the identity of this specific IOT device and send two simple calculations back to the IOT device for it to mathematically prove the identity of the server and establish the reciprocal trust that is required before deploying our proprietary version of generating AES 256 encryption keys to encrypt and send the data to report plus the results of two more simple calculations to the server to mathematically prove the identity of the IOT device again before accepting, decrypting and recording the data being reported to the server.
The last exchange of two calculated sums finishes out some house keeping issues to get ready for the next transmission between them that completely changes all the values held at both locations and proves that after those changes the data sets at both locations remain equal to one another.
Sending a hash of one table to match to the hash of the other table proves both data sets are still equal if the hashes are equal without compromising the security of either data set.
To provide the IOT device with instructions the server encrypts the control instructions and sends them in the last exchange as they are both working on their house keeping issues. The IOT device then decrypts the instructions, records them, completes all housekeeping duties, and then executes the remote control instructions independently.
Computers, smart phones and the more sophisticated devices are not as limited by power, communication range, CPU capacities, program storage capabilities, and are able to sustain bidirectional communications that simple IOT devices can not.
Bidirectional communications make data collection activities and receiving remote control instructions much more efficient. The extent today’s bidirectional devices depend upon asymmetric encryption for the protection of their remote control functions makes them vulnerable in a post quantum world.
The earlier discussion of reciprocal authentication where Sue was contacting Bob was a demonstration of a bidirectional use case for messaging, phone calls and video connections that required Sue to select Bob and then the method of contacting Bob.
Sue could have selected anyone listed in the directories available to her and any contact method that was made available to her.
The bidirectional use case for remote control the bidirectional devise although capable of using different contact methods is restricted for control purposes to only a few methods to engage in transmissions.
The most important feature in any remote control environment is making sure the correct party has and maintains control at all times. The STRAT ID GIC Implementation of reciprocal authentication records and uses time as a weapon against any attempts to interrupt our ability to establish and maintain remote control.
It is our position that it will be impossible for some attacking force to first decipher our processes, change them to meet their objectives and then conduct our processes faster than we can conduct our processes knowing both the secret calculations and secret data sets that our processes require.
Completely changing the values of the variables in the secret calculations we use makes discovering any previously used calculations worthless for determining any future calculations. Changing the variables with each transmission adheres to the principal of maintaining perfect forward security. For these reasons we believe our processes permanently secure your ability to retain remote control.
When Sue contacts Bob how does she know it is Bob she is contacting? When Bob gets contacted by Sue how does Bob know it is Sue that is contacting him? The asymmetric encryption we use today works with a private key that the person to receive contacts keeps to themselves and a public key they share with the world. Everyone just needs these two keys which is so much more efficient than the symmetric encryption explained earlier.
Bob shares his public key so Sue can encrypt and send a message to BOB who is the only one with the private key needed to decrypt Sue’s message. If Sue hashed her message before encrypting it and included that hash value in the message she sent, Bob could open her message, use his private key to decrypt it, hash the message himself, and match it to the hash Sue sent so Bob can be confident that the message as sent has not been altered, but that does not prove that it was Sue that sent the message.
Sue could have registered with a certificate authority and created a digital signature that uses both types of encryption that she could have sent in the message before hashing and encrypting it. Then when Bob uses his private key to decrypt, confirms the hash, he could check the digital certificate against the certificate authority to prove the message was from Sue and the hash shows it had not been altered. Sue would still not know if Bob ever got her message unless Bob uses Sue’s public key and a hash to send an encrypted and hashed message with his digital certificate to Sue telling her he got the original message. In most cases this second transmission never happens and Sue just assumes Bob will get her message creating a weakness in the current process.
When quantum computers get real the whole public private key asymmetric encryption and the digital certificates based on asymmetric encryption will no longer work and we will need to increase the size of our hashes and the size of our symmetric keys above 128 for them to be viable. Providing a temporary fix to this authentication problem is part of what the NIST technologies will need to address when rolled out the first quarter of 2022.
James O'Brien CEO, principal inventor, former CPA, designed, and has managed EMR software for a Tampa Medical Clinic since 2002. Umang Sachan is managing his crew of software engineers, has earned his place as our technical cofounder by building the first proof of concept of US Patent 8799022 and they are building and testing our current software projects including an overhaul of our EMR software
Encouraging our enrollees to provide detailed marketing information upon enrolling with the understanding that it would be held in a de-identified database allows our tech to combine it with their de-identified communication and transaction data securely.
.png)