Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity such as a hub to manage authentication, for example. In some instances, the third party may also perform endpoint selection (e.g., load balancing) by providing a particular endpoint along with the token.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity such as a hub to manage authentication, for example. In some instances, the third party may also perform endpoint selection (e.g., load balancing) by providing a particular endpoint along with the token.

Abstract: A plaintext and cryptographic key are used to generate an initialization vector to be used in a cryptographic algorithm, such as an encryption algorithm. In some examples, the plaintext and cryptographic key are input into an effectively one-way function, such as a cryptographic hash function, the output of which is usable as an initialization vector. Cryptographic keys may be rotated probabilistically based at least in part on probabilities of output collisions of the effectively one-way function to ensure a low probability of two different plaintexts resulting in calculation of the same initialization vector for use with the same cryptographic key.

Abstract: A web of trust in a distributed system is established. A root of trust for at least two components in the distributed system validates information for the distributed system. The validated information is then used to create additional information for the distributed system. Versions of the information are usable to validate subsequent versions of the information such that validation of a version of the information can be performed by using one or more previous versions to verify that the version is a valid successor of a previously validated previous version.

Abstract: A service provider provides virtual computing services using a fleet of one or more host computer systems. Each of the host computer systems may be equipped with a trusted platform module (“TPM”). The service provider, the host computer systems, and the virtual computing environments generate attestations that prove the integrity of the system. The attestations are signed with a one-time-use cryptographic key that is verifiable against the public keys of the service provider, a host computer system, and a virtual computing environment. The public key of the host computer system is integrated into a hash tree that links the public key of the host computer system to the public key of the service provider. The public key of the virtual computing environment is signed using a one-time-use graphic key issued to the host computer system that hosts the virtual computing environment.

Abstract: A first entity having a first set of tagged data and a second entity having a second set of tagged data share data that is selected based on a set of common tags present in both the first and second sets of tagged data. The set of common tags is determined using a private set intersection protocol that, in many examples, preserves the privacy of the two entities. In an embodiment, each entity identifies a set of data objects associated with the set of common tags, and another private set intersection protocol is performed to identify a set of common data objects available to both entities. Each entity provides, to the other entity, those data objects associated with the set of common tags that are not in the set of common data objects available to both entities thereby providing a matching set of data objects to both entities.

Abstract: Performing cryptographic operations such as encryption and decryption may be computationally expensive. In some contexts, initialization vectors and keystreams operable to perform encryption operations are generated and stored in a repository, and later retrieved for use in performing encryption operations. Multiple devices in a distributed system can each generate and store a subset of a larger set of keystreams.

Abstract: A computer system performs cryptographic operations as a service. The computer system is configured to allow users of the service to maintain control of their respective cryptographic material. The computer system uses inaccessible cryptographic material to encrypt a user's cryptographic material in a token that is then provided to the user. The user is unable to access a plaintext copy of the cryptographic material in the token, but can provide the token back to the service to cause the service to decrypt and use the cryptographic material.

Abstract: A request to perform a cryptographic operation is received, the request including a first identifier assigned to a key group, the key group comprising a plurality of second identifiers, with the plurality of second identifiers corresponding to a plurality of cryptographic keys. A second identifier is determined, according to a distribution scheme, from the plurality of second identifiers, and the cryptographic operation is performed using a cryptographic key of the plurality of cryptographic keys that corresponds to the second identifier that was determined.

Abstract: A device is provisioned and authorized for use on a network. The device may generate a cryptographic key and provide a digital certificate the cryptographic key, a hardware identifier, and attribute information and provide such information to an authorization host as part of the provisioning process. The authorization host may use attribute information to determine whether to authorize the device for use on the network, and whether the generated cryptographic key should be trusted for use on the network.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity such as a hub to manage authentication, for example. In some instances, the third party may also perform endpoint selection (e.g., load balancing) by providing a particular endpoint along with the token.

Abstract: A first public key is generated based at least in part on a first plurality of signing keys and a second public key is generated based at least in part on a second plurality of signing keys. The signing keys may be used to generate digital signatures. The second public key may be made available to verify a digital signature generated using a signing key from the second plurality of signing keys. In some cases, a first Merkle tree may be formed by the first public key and the first plurality of signing keys, and a second Merkle tree may be formed by the second public key, the first public key, and the second plurality of signing keys.

Abstract: A cryptographic key management service receives a request to import a first cryptographic key. In response to the request, the service creates a public cryptographic key and a private cryptographic key. The private cryptographic key is encrypted using a second cryptographic key to create an import key token. The import key token and the public cryptographic key are provided in response to the request. The service receives an encrypted first cryptographic key, which the service decrypts using the private cryptographic key to obtain the first cryptographic key. The service stores the first cryptographic key and enables its use for the performance of cryptographic operations.

Abstract: Protection against the obsolescence of cryptographic algorithms is provided by generating a cryptographic key pair for future use and storing the public key on a device. The cryptographic key pair supports a signature scheme that is potentially resistant to quantum computing attacks. In an embodiment, a key management server generates a set of one-time use keys sufficient to sign the anticipated number of software updates to be applied to a device. The key management server provides a public key which is stored on the device for later use. In an embodiment, an update to the device us signed with the one-time-use private key, and can be authenticated by the device using the public key. In an embodiment, the key pair supports the use of a one-time signature technique such as a Merkle signature scheme, Winternitz signature, or Lampert signature.

Abstract: A service provider provides virtual computing services using a fleet of one or more host computer systems. Each of the host computer systems may be equipped with a trusted platform module (“TPM”). The service provider, the host computer systems, and the virtual computing environments generate attestations that prove the integrity of the system. The attestations are signed with a one-time-use cryptographic key that is verifiable against the public keys of the service provider, a host computer system, and a virtual computing environment. The public key of the host computer system is integrated into a hash tree that links the public key of the host computer system to the public key of the service provider. The public key of the virtual computing environment is signed using a one-time-use graphic key issued to the host computer system that hosts the virtual computing environment.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity such as a hub to manage authentication, for example. In some instances, the third party may also perform endpoint selection (e.g., load balancing) by providing a particular endpoint along with the token.

Abstract: Plaintext data is encrypted and decrypted using a symmetric encryption algorithm that generates a sequence of pseudorandom values from a cryptographic key. A portion of the sequence of pseudorandom values is discarded. For example, in an embodiment, each value in the sequence of pseudorandom values is truncated by a number of bits. Encryption and decryption is performed by combining plaintext or ciphertext with the truncated sequence of pseudorandom values. In an embodiment, the combination is made by performing a bitwise exclusive or operation between the truncated pseudorandom values and the plaintext or ciphertext. In an embodiment, a number of bits discarded from each value is encoded into a message authentication code which is provided with any resulting ciphertext.

Abstract: Clients within a computing environment may establish a secure communication session. Sometimes, a client may trust another client to read, but not modify, a message. Clients may utilize a cryptography service to generate a message protected against improper modification. Clients may utilize a cryptography service to verify whether a protected message has been improperly modified.

Abstract: A trusted co-processor can provide a hardware-based observation point into the operation of a host machine owned by a resource provider or other such entity. The co-processor can be installed via a peripheral card on a fast bus, such as a PCI bus, on the host machine. The provider can provide the customer with expected information that the customer can verify through a request to an application programming interface (API) of the card, and after the customer verifies the information the customer can take logical ownership of the card and lock out the provider. The card can then function as a trusted but limited environment that is programmable by the customer. The customer can subsequently submit verification requests to the API to ensure that the host has not been unexpectedly modified or is otherwise operating as expected.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity to manage authentication, for example. In some instances, the third party may also perform endpoint selection by providing a particular endpoint along with the token. The particular cipher suite applied in a particular implementation may be configurable. The process is applicable to either implicit key confirmation (e.g., handshake negotiation) or explicit key confirmation (e.g., full negotiation).