"Explain it like I'm five"
Register with Hopr to receive access to our container repo, license, and key. Complete self-serve onboarding through the Hopr Help Center (yes it’s that simple!).
An average DevOps can complete this step in a few days.
We provide DevOps with YAML templates and instructions to get started. DevOps edit a handful of configuration values.
They select a specific CHIPS™ algorithm to achieve identical secrets generation with other trusted workloads.
The YAML is run in the CD pipeline and deploys configured sidecars with a host workload.
Some simple tests verify proper operation before live operation begins.
Once live, all capabilities of Hopr Connect are immediately effective.
Hopr provides a dashboard for information on sidecar-workload activity and connections.
Sidecar logs of failed connections from untrusted sources are also available to customers within their network.
Synchronous Ephemeral Encryption (SEE™) is a patented protocol that is self-synchronizes connections between endpoints. Synchronization occurs at the start of a connection without a key exchange.
Without successful decryption, a received message will fail. This could happen due to timing differences in credential rotation. If this occurs with a trusted workload, then we re-build the secret and re-send the message.
The "CHIPS™ algorithm" is highly variable and unique. Algorithms in a sidecar can number in the hundreds-of-thousands. It is unlikely that threat actors will guess or find your particular algorithm within the library of very large number of algorithms.
Hopr Connect can be configured to encrypt data at either layer 4 or layer 7 of the OSI network stack. Layer 4 supports network load balancers (NLB) and layer 7 supports application load balancers (ALB). Both sidecar endpoints in a connection must use the same layer for encryption.
SEE™ builds comprehensive end-to-end encrypted connections over the entire route between trusted workloads.
mTLS is not supported everywhere in the cloud an may terminate at "identity domain boundaries" between workloads where PKI certificates lose their acceptance and trust.
mTLS in the cloud also relies on automated PKI certificates which lack verification of workload trust when issued. And each certificate issued is an entirely new identity.
There is a significant amount of dynamism (variability) in the seed elements used in CHIPS algorithms. It begins with a vast number of URLs where dynamic information can be found, and increases with the many possible locations at an URL.
It increases further because algorithms have many possible structures to alter or modify the dynamic elements. This includes nearly two-dozen variables, each of which has many possible values.
Yes, symmetric encryption (used by Hopr Connect) is expected to be quantum safe for about a decade after quantum computing breaks asymmetric encryption. Hopr Connect uses a FIPS 140-2 and -3 cryptographic library. AES256 and is quantum resistant. An additional degree of quantum resistance is provided by the short lifetime of SEE™ keys, bringing it closer to being quantum safe.
The overhead added occurs only when connections begin. Hopr Connect adds 2 messages to the overall message count for each workload.
If two workloads were to interact in a session of 100 API calls and responses, then the additional overhead for the security provided by Hopr Connect would be 4%.
