| Internet-Draft | SCC | October 2020 |
| Mindermann & Teis | Expires 21 April 2021 | [Page] |
Choosing secure cryptography algorithms and their corresponding parameters is difficult. Also, current cryptography APIs cannot change their default configuration which renders them inherently insecure. The Secure Crypto Config provides a method that allows cryptography libraries to change the default cryptography algorithms over time and at the same time stay compatible with previous cryptography operations. This is achieved by combining three things standardized by the Secure Crypto Config: (1) A process that is repeated every two years, where a new set of default configurations for standardized cryptography primitives is published in a specific format. (2) A Secure Crypto Config Interface that describes a common API to use cryptography primitives in software (3) using COSE to derive the parameters from output of cryptography primitives, otherwise future changes of the default configuration would change existing applications behavior.¶
Comments are solicited and should be addressed to the GitHub repository issue tracker and/or the author(s)¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 April 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Cryptography needs standardization to work across various domains and to be interoperable between different implementations. One domain that is not covered sufficiently by cryptography standards is the selection and maintenance of cryptography algorithms and their parameters. Choosing an appropriate and secure cryptography algorithm alone is difficult. Yet, even more difficult is the choice of the required and matching parameters for that algorithm (e.g. Argon2 has 10 input parameters). After the choice has been made, all involved parties need to use exactly this configuration. There is no specification on how the chosen cryptography configuration should be stored, distributed and retrieved. Furthermore, supporting more than one configuration or being able to add future configurations is not defined. That reduces software compatibility and increases maintenance efforts.¶
Cryptography algorithm implementations, regardless of for one algorithm or multiple ones, offer some kind of Application Programming Interface for developers to use the algorithms. Yet, in many cases these interfaces provide no abstraction from the underlying algorithm but expose much of the internal states and parameters. Also the more abstracting interfaces, usually found in the standard libraries of programming languages, require users to have much cryptography experience to use them correctly and securely. Moreover, even approaches that tried to increase usability by providing defaults, these defaults become quickly outdated but cannot be changed in the interface anymore as applications using these defaults rely on that functionality.¶
It sounds a lot like a problem for software engineering and not for cryptography standardization. But software engineering alone cannot provide a programming interface for cryptography algorithms that also works for future algorithms and parameters and at the same time is able to change the default implementation easily. Both the choice of the algorithm/parameters and the default behavior must be automated and standardized to remove this burden from developers and to make cryptography work by default and in the intended secure way.¶
The Secure Crypto Config approaches this problem first by providing a regular updated list of secure cryptography algorithms and corresponding parameters for common cryptography use cases. Second, it provides a standardized Application Programming Interface which provides the Secure Crypto Config in a misuse resistant way to developers. Third, it leverages an already standardized format ([RFC8152]) to store the used parameters alongside the results of cryptography operations. That ensures that future implementations can change their default cryptography algorithms but still parse the used configuration from existing data and perform the required cryptography operations on it.¶
Each of these approaches could be used on its own. Yet, the combination of them allows software to be more easy to maintain, more compatible to other cryptography implementations and to future security developments, and most importantly more secure.¶
The Secure Crypto Config makes common assumptions that are not true for all possible scenarios. In cases where security experts are indeed involved and more implementation choices have to be made, the Secure Crypto Config still allows the usage of predefined or even custom cryptography algorithms and parameters.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The terms "API", "attack", "authenticity", "availability", "break", "brute force", "cipher", "ciphertext", "classified", "classification level", "confidentiality", "cryptographic hash", "encrypt", "encryption", "initialization vector (IV)", "integrity", "key", "mode", "nonce", "password", "plain text", "plaintext", "protocol", "security", "security level", "threat", "trust", in this document are to be interpreted as described in [RFC4949].¶
The term "hash" is used as a synonym for "cryptographic hash".¶
The term "cryptographic primitive" is used in this document to describe a generic building block used in the field of cryptography e.g. Hashing, symmetric encryption.¶
The Secure Crypto Config has the following main use cases:¶
The Secure Crypto Config covers cryptography algorithm and parameter configurations for widely used cryptography use cases defined in the following sections.¶
Symmetric Encryption is an important cryptographic primitive especially as it is usually multiple magnitudes faster both for encryption and decryption than asymmetric cryptography. Yet, the secret has to be shared with all participants.¶
The only expected input parameters by cryptography users:¶
Expected output: ciphertext.¶
Additional Parameters often required in practice:¶
Possible secure usage:¶
Beside symmetric encryption is asymmetric encryption another important cryptographic primitive to considered.¶
The only expected input parameters for encryption:¶
Expected output: ciphertext.¶
The only expected input parameters for decryption:¶
Possible secure usage:¶
Hashing is an important cryptographic primitives and is often needed as a part of many other cryptographic use cases e.g. password derivation.¶
The only expected input parameters by cryptography users:¶
Expected output: hash.¶
Possible secure usage:¶
The secure storage of passwords requires hashing. Yet, password hashing requires that the hashing can not be performed very fast to prevent attackers from guessing/brute-forcing passwords from leaks or against the live system. E.g. it is totally fine for users if the login takes 0.1 seconds instead of microseconds. This results in special families of hash algorithms which offer additional tuning parameters.¶
The only expected input parameters by cryptography users:¶
Expected output: hash.¶
Possible secure usage:¶
A key is necessary for many cryptographic use cases e.g. symmetric and asymmetric encryption. Therefore, key generation is an important part while implementing cryptographic code.¶
The only expected input is the intended use case.¶
Expected output: key.¶
Possible secure generation:¶
Signing is an important and often needed cryptographic use case. It is based on the principle of asymmetrical encryption.¶
The only expected input parameters for signing:¶
Expected output: signature.¶
The only expected input parameters for verifying the signature:¶
Expected output: valid/not-valid.¶
Possible secure usage:¶
In the following all requirements are listed that regard the Secure Crypto Config or the Secure Crypto Config Interface.¶
Consensus Finding Process and entities:¶
Publication Format and Distribution Requirements:¶
General:¶
Human readable¶
Machine readable¶
Cryptography library integration requirements:¶
General Requirements:¶
The Secure Crypto Config assumes that both the proposed algorithms and the implementations (cryptography libraries) for the cryptography primitives are secure. This also means that side-channel attacks are not considered explicitly. It is also assumed that programmers, software engineers and other humans are going to use cryptography. They are going to make implementation choices without being able to consult cryptography and security experts and without understanding cryptography related documentation fully. This also means that it is not considered best practice to assume or propose that only cryptography experts (should) use cryptography (primitives/libraries).¶
The Secure Crypto Config must be able to provide a secure parameter set for different security levels. These security levels depend on the following security constraints: Information classification (Secret, Confidential), Longevity (less than one day, more than a day), Constrained devices (constrained, not constrained). They are defined in Section 3.6 below. The Secure Crypto Config provides 5 common security levels for which official algorithm/parameter choices are published.¶
Confidential information, regardless of the other two constraints¶
Secret information, less than one day longevity, constrained device¶
Secret information, less than one day longevity, non-constrained device¶
Secret information, more than a day longevity, constrained device¶
Secret information, more than a day longevity, non-constrained device¶
Information classification within this document is about the confidentiality of the information. Not all information is equally confidential, e.g. it can be classified into different classes of information. For governmental institutions usually three classes are used: Confidential, Secret, or Top Secret. The Secure Crypto Config considers only Confidential and Secret for its standardized security levels. Further levels with other classifications can be added by other organizations. Additionally, in common (non-governmental) use cases data is not labelled with an information class. Hence, often only one class is chosen for the cryptography processing of all data.¶
The Secure Crypto Config does not endorse a definition of the information classes, yet Secret information is to be considered to have higher confidentiality requirements than Confidential information.¶
The time how long information has to be kept confidential can influence cryptography parameters a lot. Usually what you talked about with your friends should be kept confidential for a life time. Yet, a public trade transaction must only be confidential until the trade was executed which can happen in milliseconds. It directly influences a very important attacker resource: The time an attacker has to try to gain access to the confidential information. The Secure Crypto Config considers only two ranges of longevity for its standardized security levels: short longevity of less than one day and long longevity of a day or more than a day. Further levels with other longevity levels can be added by other organizations.¶
For cryptography often complex computations have to be executed. Yet, not all environments have the same hardware resources available. E.g. it is not always the case that the used processors have dedicated cryptography hardware or even specialized execution units or instruction sets like [AESNI]. Detailed discussion and definitions can be found in [RFC7228]. Yet, their definitions are too concrete to be used in the Secure Crypto Config's standardized security levels. Therefore, the Secure Crypto Config uses defines constraint devices not based on concrete processing power (e.g. 100k instructions per second):¶
A device is constrained when it has multiple orders of magnitudes less resources than a current (not a new one, but broadly in use at the time of publication of a Secure Crypto Config!) standard personal computer.¶
For example if a current standard personal computer can encrypt with 1 GiB/s, a constrained device would be all devices that can only perform the same cryptography operation with less than 10 MiB/s. Resources can be everything important for cryptography like dedicated cryptography hardware, instruction sets, memory, power consumption, storage space, communication bandwidth, latency etc. The Secure Crypto Config considers only constrained and non-constrained for its standardized security levels. Further levels with other constrained resource definitions can be added by other organizations.¶
n-Bit Security Level:¶
The Secure Crypto Config considers only the following same attacker resources and capabilities for all standardized security levels:¶
Further security levels with other attacker definitions can be added by other organizations.¶
To provide a Secure Crypto Config it is necessary to agree upon a secure and appropriate cryptographic parameter set for each security level (see Section 3). This must happen in a common consensus finding process which takes place during a regular intervals. The consensuns finding process is based on the established RFC process during which the Secure Crypto Config Working Group decides in cooperation with the Crypto Forum Research Group (CFRG) and other institutions like the Bundesamt fuer Sicherheit in der Informationstechnik (BSI) or the National Institute of Standards and Technology (NIST) for a set of secure parameters. After the successful decision the agreed on parameters can be added in the defined pulibcation data structures (see Section 5.4) and provided on the repository platform.¶
Consensus must be found two years after the last consensus was found. This ensures that there is a new Secure Crypto Config every two years, even if the configuration itself has not changed. There is a regular process and an emergency process to release Secure Crypto Configurations.¶
The process has three phases that MUST be finalized within 2 years:¶
During the Proposal phase the proposed algorithms and all necessary parameters should be submitted in table form for each security level and defined cryptographic use case like proposed. This table format is simply structured and is easy to read by human as the Consensus finding phase can only be done manually. It is important that the parameters for each cryptographic use case depending on its security level can be found easily by the participants of the consensus finding process such that it is possible to get to an agreement faster.¶
In cases when a regularly still valid Secure Crypto Config would become insecure regarding either a proposed algorithm or a proposed parameter choice it must be revised with the following process:¶
Examples for emergency cases are drastically better brute force algorithms or brute force performance (e.g. quantum computers/algorithms), drastically discovered flaws in proposed algorithms and their configurations.¶
An applied emergency process results in the problem that currently used Secure Crypto Config Interface versions are no longer up-to-date, because they are still supporting the no longer secure algorithms. Therefore the corresponding algorithms need to be marked as insecure. If e.g. an proposed algorithm gets insecure this can be marked inside the corresponding Secure Crypto Config IANA registry entry as no longer proposed to make the users aware of its insecurity. The Working Group itself can decide when to alter the Secure Crypto Config IANA registry.¶
The Secure Crypto Config MUST only propose cryptography algorithms and parameters that fulfill the following requirements:¶
The Secure Crypto Config SHOULD only propose cryptography algorithms and parameters that fulfill the following requirements:¶
Entities that participate in the proposal phase SHOULD have significant cryptography expertise. Entities that participate in the consensus finding phase MUST have significant cryptography expertise. Cryptographic expertise is defined by the Secure Crypto Config Working Group or the CFRG.¶
In general the Secure Crypto Config is published via JSON-files in an official repository. The Secure Crypto Config also utilizes IANA registries.¶
The Secure Crypto Config Format is regularly published in a specific year. Therefore, the Secure Crypto Config format MUST use the following versioning format: YYYY-PATCH. YYYY is a positive integer describing the year (using the Gregorian calendar, and considering the year that has not ended in all time zones, cf. Anywhere on Earth Time) this specific Secure Crypto Config was published. PATCH is a positive integer starting at 0 and only increasing for emergency releases.¶
Naming of official released SCCs must follow this format:¶
SCC_**Version**_LEVEL_**Security Level Number**¶
E.g. a Secure Crypto Config for Security Level 5 release in 2020 the first time (so no patch version) would be named: SCC_2020-00_LEVEL_5¶
Naming of files is not regulated, only the content is standards relevant.
Yet, the Secure Crypto Config Files should use the mentioned naming convention as well adding a suffix (file type ending) .json to prevent ambiguity and remove implementation choices:¶
SCC_**Version**_LEVEL_**Security Level Number.json**¶
NOT NEEDED?, as the Secure Crypto Config uses other registries, e.g. COSE. No final decision, yet.¶
The Secure Crypto Config requires one IANA Registry with the following columns:¶
Algorithm-Parameter-Identifier: MUST only consist of uppercase alphanumeric characters and underscores. Depending on the use case the Algorithm Parameter Identifier can be constructed differently. We propose the following schemes:¶
| SCC Version | AlgParam Identifier | Reference | Description |
|---|---|---|---|
| 2020-01 | AES_GCM_256_128_128 | [RFC8152] | AES 256 with GCM and 128 bit tag and random nonce |
The Secure Crypto Config can only propose cryptography algorithms and parameters that have been standardized. Therefore it refers to the following IANA registries:¶
Used registries must define all required parameters for an algorithm to implement it without ambiguity. E.g. implementations must not be able to choose other parameter values for a cryptography algorithm and parameter combination.¶
For each defined security level a distinct JSON-file must be provided. These files must adhere to the common schema and shown in Figure 1 and described in the following.¶
{
"PolicyName": "SCC_SecurityLevel_Security Level Number",
"Publisher": [
{
"name": "Publisher name",
"URL": "URL corresponding to publisher"
}
],
"SecurityLevel" : "Security Level Number",
"Version": "YYYY-Patch",
"PolicyIssueDate": "YYYY-MM-DD",
"Expiry": "YYYY-MM-DD",
"Usage": {
"SymmetricEncryption": [
"Algorithm 1",
"Algorithm 2"
],
"AsymmetricEncryption": [
"Algorithm 1",
"Algorithm 2"
],
"Hashing": [
"Algorithm 1",
"Algorithm 2"
],
"PasswordHashing": [
"Algorithm 1",
"Algorithm 2"
],
"Signing": [
"Algorithm 1",
"Algorithm 2"
]
}
}
Publisher: Contains an array of all parties that participated in the consensus finding process¶
Usage: Contains an array of objects for each cryptographic use case defined in Section 1.3.2.¶
This format allows custom algorithm/parameter definitions both by overwriting use cases completely or by adding only specific algorithm identifiers via custom configurations.¶
The Secure Crypto Config can not only be used in an automatic way, but also provide the cryptography algorithms and parameters for humans. The human readable format must be derived from the JSON-files both to protect from copy-paste-errors and to validate the cryptographic signatures. Yet, the human readable format or publication page itself must not be cryptographically protected. There should be one accessible resource, e.g. a webpage, where the source format (JSON-files) are automatically used for displaying them in appropriate ways (e.g. tables with various sorting and searching options).¶
The needed Secure Crypto Config files should be published at an official Github repository. There all current versions will be provided during the interval of the Publication phase (see Section 4.1.1). Additionally all previously published files are still stored at this location even if new versions are published.¶
scc-repo
- configs
- 2020
- 00
- SCC_2020-00_LEVEL_1.json
- SCC_2020-00_LEVEL_1.signature1
- SCC_2020-00_LEVEL_1.signature2
- SCC_2020-00_LEVEL_2.json
- SCC_2020-00_LEVEL_2.signature1
- SCC_2020-00_LEVEL_2.signature2
- SCC_2020-00_LEVEL_3.json
- SCC_2020-00_LEVEL_3.signature1
- SCC_2020-00_LEVEL_3.signature2
- SCC_2020-00_LEVEL_4.json
- SCC_2020-00_LEVEL_4.signature1
- SCC_2020-00_LEVEL_4.signature2
- SCC_2020-00_LEVEL_5.json
- SCC_2020-00_LEVEL_5.signature1
- SCC_2020-00_LEVEL_5.signature2
- 01
- 02
- 2021
- 2022
- 2023
- 2024
scc-repo
- configs
- a
- b
- 0c1
- ReallySecure
- 0x1111
- SCC_2020-00_LEVEL_1.json
- SCC_2020-00_LEVEL_1.signature1
- SCC_2020-00_LEVEL_1.signature2
- SCC_2020-00_LEVEL_2.json
- SCC_2020-00_LEVEL_2.signature1
- SCC_2020-00_LEVEL_2.signature2
- SCC_2020-00_LEVEL_3.json
- SCC_2020-00_LEVEL_3.signature1
- SCC_2020-00_LEVEL_3.signature2
- SCC_2020-00_LEVEL_4.json
- SCC_2020-00_LEVEL_4.signature1
- SCC_2020-00_LEVEL_4.signature2
- SCC_2020-00_LEVEL_5.json
- SCC_2020-00_LEVEL_5.signature1
- SCC_2020-00_LEVEL_5.signature2
- asdf
- afd
- af
The Secure Crypto Config configuration files are expected to be in any folder hierarchy below the folder configs-folder.
Each JSON file should be accompanied by corresponding signature files that have the same filename without extension as the JSON file, suffixed by -signatureX where X is a counter starting at 1.¶
[ ] TODO what kind of signing process should be used?¶
Each JSON-file should be accompanied by at least two signatures. Both signatures are stored in different files on the same level as their corresponding Secure Crypto Config file to reduce the parsing effort. The signatures should be generated by entities defined by the Secure Crypto Config Working Group. They are responsible to publish and renew the used public keys. For signing of the corresponding Secure Crypto Config JSON files openssl could be used. The public keys needed for validation are published in the official repository of the Secure Crypto Config.¶
This section describes the programming interface that provides the Secure Crypto Config. The Secure Crypto Config Interface is generic and describes the API that should to be used by each programming language.¶
The implementation of the Secure Crypto Config Interface MUST follow Semantic Versioning, which specifies a version format of X.Y.Z (Major.Minor.Patch) and semantics when to increase which version part. It would be beneficial if the release of a new Interface version gets synchronized with the publication of a new Secure Crypto Config. It should be possible to support the newly defined parameters of Secure Crypto Config in the interface as soon as possible.¶
There are two different possibilities to work with the Secure Crypto Config: - The preferred option is to use the Secure Crypto Configs that will be delivered within the Interface. In each new Interface version the current Secure Crypto Configs will be added such that always the newest Secure Crypto Configs at the time of the Interface release will be supported. Previous Secure Crypto Configs will remain inside the Interface such that also older ones can still be used. - Another option is to define a specific path to your own/derived versions of the Secure Crypto Configs with the same structure of the files as described in Section 5.4 but with other values than in the official ones.¶
The Interface will process the Secure Crypto Configs as follows:¶
configs folder exists.¶
configs in the hierarchy look inside that folder and check the existence of JSON files that need to be considered.
This check will happen recursively for all folders inside the hierarchy.¶
The parsing of each valid JSON file must be done as follows:¶
Each Secure Crypto Config Interface must be published in such a way that it uses (a copy of) the recent Secure Crypto Config repository.¶
The Secure Crypto Config will be stored inside the subfolder scc-configs which should be located in the Interface's src-folder if existent.
The structure of the scc-configs folder will be the same as in the described hierarchy of the Github repository.
In any new version of the Interface the latest published Secure Crypto Config and its signatures must be used.¶
If new Secure Crypto Configs will be published for which no published version of the Interface is available, the custom repository approach can be used as described in the following.¶
It is also possible to use a different path to the Secure Crypto Configs.
As also derived versions of the Secure Crypto Config for specific needs should be supported it will also be feasible to define a path to own or derived files which differentiate from the default src/scc-configs/configs folder.
For this case a method for setting and using a specific path must be provided by the Interface.¶
The check for valid signature of the Secure Crypto Configs is always made before every actual usage of the Interface functionalities. In this way it is possible to guarantee that the entity using the Interface only works with valid Secure Crypto Configs and circumvents the risk of forged file contents. The public key needed for validity can be found in the official Github repository. If own derived Secure Crypto Configs are created than it can be possible that no validation process is needed for these files.¶
Intended methods and parameters included in the Java interface are described in Figure 5.¶
Cryptography algorithms require different parameters. The Secure Crypto Config Interface considers the following types of parameters:¶
It should be possible to have user specified parameters such as the key/nonce length explicitly given by the user, but also a performance mode which makes an evaluation for each configuration and give back a prioritized list for each configuration. In this way it is possible to select parameters depending on systems properties. Such a parameter choice would be beneficial e.g. in the case of Argon2 in which one parameter for the memory usage must be given. This choice should be chosen on the base of the corresponding system. That kind of parameter selection can be seen e.g. in Libpasta Tuning, which returns a secure parameter set depending on executed evaluations.¶
A Secure Crypto Config Interface must offer the following additional methods regarding the configuration - A method that returns a human readable version of the currently used Secure Crypto Config - A method that returns the currently used cryptography algorithm and parameters for a given use case - A method that validates the content of a Secure Crypto Config JSON file and one or more signatures¶
The SCC could be provided on a suitable platform (?) and is accessible over the network (adversaries? e.g. http connection)¶
Cryptography libraries should provide the above mentioned Secure Crypto Config Interface. Until a common cryptography library provides the Secure Crypto Config Interface itself, there should be wrapper implementations that provide the Secure Crypto Config Interface and make use of the programming languages' standard cryptography library.¶
When new cryptography algorithm and/or parameter/mode/etc standards are created, they should contain a section mentioning the creating of the proposed secure parameter sets in the above mentioned IANA registries. This ensures that new cryptography algorithms and parameter sets are available faster for the Secure Crypto Config Interface implementations to use.¶
The Secure Crypto Config does not apply to all use cases for cryptography and usage of cryptography primitives. It is meant to provide secure defaults for the most common use cases and for non-expert programmers. Additionally, non-experts may still implement vulnerable code by using the Secure Crypto Config. Yet, it should reduce the vulnerabilities from making the wrong choices about parameters for cryptography primitives.¶
The Secure Crypto Config makes a best effort to be as up-to-date with recent discoveries, research and developments in cryptography algorithms as possible. Following this it strives to publish cryptography algorithms and corresponding parameter choices for common use cases.¶
Yet, the Secure Crypto Config and the involved parties working on and publishing it doe not guarantee security for the proposed parameter configurations or any entity making use of it. E.g. a new algorithm that can do brute-force attacks exponentially faster could be existing or published right after the publication of the most recent Secure Crypto Config was published itself.¶
There are different possibilities in which a potential adversary could intervene during the creation as well as after the publication of the Secure Crypto Config. These attack scenarios must be considered and prevented.¶
The data structure (see Section 5.4) defined in this document uses the JSON format as defined in [RFC8259].¶
{
"PolicyName" : "SCC_SecurityLevel_5",
"Publisher" : [
{
"name" : "Crypto Forum Research Group",
"URL" : "https://irtf.org/cfrg"
},
{
"name" : "BSI",
"URL" : "https://BSI"
}
],
"SecurityLevel" : "5",
"Version" : "2020-0",
"PolicyIssueDate" : "2020-04-20",
"Expiry" : "2023-04-21",
"Usage" : {
"SymmetricEncryption" : [
"AES_GCM_256_96",
"AES_GCM_192_96"
],
"AsymmetricEncryption" : [
"RSA_SHA_512",
"RSA_SHA_256"
],
"Hashing" : [
"SHA3_512",
"SHA_512"
],
"Signing" : [
"ECDSA_512",
"ECDSA_384"
],
"PasswordHashing" : [
"PBKDF_SHA_512",
"SHA_512_64"
]
}
}
package org.securecryptoconfig;
import java.nio.charset.Charset;
import java.security.InvalidKeyException;
import org.securecryptoconfig.SCCKey.KeyType;
import org.securecryptoconfig.SCCKey.KeyUseCase;
import COSE.CoseException;
public abstract interface SecureCryptoConfigInterface {
//Symmetric
public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, byte[] plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
throws CoseException, InvalidKeyException, SCCException;
public PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext sccciphertext)
throws CoseException, InvalidKeyException;
// Asymmetric
public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, byte[] plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
throws CoseException, InvalidKeyException, SCCException;
public PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
throws CoseException, InvalidKeyException, SCCException;
// Hashing
public AbstractSCCHash hash(PlaintextContainerInterface plaintext) throws CoseException, SCCException;
public AbstractSCCHash hash(byte[] plaintext) throws CoseException, SCCException;
public AbstractSCCHash updateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash)
throws CoseException, SCCException;
public AbstractSCCHash updateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException;
public boolean validateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash)
throws CoseException, SCCException;
public boolean validateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException;
// Digital Signature
public AbstractSCCSignature sign(AbstractSCCKey key, PlaintextContainerInterface plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCSignature sign(AbstractSCCKey key, byte[] plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCSignature updateSignature(AbstractSCCKey key, PlaintextContainerInterface plaintext)
throws CoseException, InvalidKeyException, SCCException;
public AbstractSCCSignature updateSignature(AbstractSCCKey key, byte[] plaintext)
throws CoseException, InvalidKeyException, SCCException;
public boolean validateSignature(AbstractSCCKey key, AbstractSCCSignature signature)
throws InvalidKeyException, SCCException;
public boolean validateSignature(AbstractSCCKey key, byte[] signature) throws InvalidKeyException, SCCException;
// Password Hashing
public AbstractSCCPasswordHash passwordHash(PlaintextContainerInterface password)
throws CoseException, SCCException;
public AbstractSCCPasswordHash passwordHash(byte[] password) throws CoseException, SCCException;
public boolean validatePasswordHash(PlaintextContainerInterface password, AbstractSCCPasswordHash passwordhash)
throws CoseException, SCCException;
public boolean validatePasswordHash(byte[] password, AbstractSCCPasswordHash passwordhash)
throws CoseException, SCCException;
}
abstract interface PlaintextContainerInterface {
public abstract byte[] toBytes();
public abstract String toString(Charset c);
@Override
public abstract String toString();
public abstract boolean validateHash(AbstractSCCHash hash) throws SCCException;
public abstract boolean validatePasswordHash(AbstractSCCPasswordHash passwordHash) throws SCCException;
public abstract AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCSignature sign(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCHash hash() throws SCCException;
public abstract AbstractSCCPasswordHash passwordHash() throws SCCException;
}
abstract class AbstractSCCCiphertext {
byte[] msg;
protected AbstractSCCCiphertext(byte[] msg) {
this.msg = msg;
}
public abstract byte[] toBytes();
@Override
public abstract String toString();
public abstract PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key) throws SCCException;
public abstract PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key) throws SCCException;
}
abstract class AbstractSCCKey {
KeyType type;
byte[] privateKey, publicKey;
String algorithm;
protected AbstractSCCKey(KeyType type, byte[] publicKey, byte[] privateKey, String algorithm) {
this.type = type;
this.publicKey = publicKey;
this.privateKey = privateKey;
this.algorithm = algorithm;
}
public abstract byte[] toBytes() throws InvalidKeyException;
public abstract byte[] getPublicKeyBytes() throws InvalidKeyException;
public abstract byte[] getPrivateKeyBytes() throws InvalidKeyException;
public abstract KeyType getKeyType();
public abstract String getAlgorithm();
}
abstract class AbstractSCCHash {
byte[] hashMsg;
protected AbstractSCCHash(byte[] hashMsg) {
this.hashMsg = hashMsg;
}
public abstract byte[] toBytes();
@Override
public abstract String toString();
public abstract boolean validateHash(PlaintextContainerInterface plaintext) throws SCCException;
public abstract boolean validateHash(byte[] plaintext) throws SCCException;
public abstract AbstractSCCHash updateHash(PlaintextContainerInterface plaintext) throws SCCException;
public abstract AbstractSCCHash updateHash(byte[] plaintext) throws SCCException;
}
abstract class AbstractSCCPasswordHash {
byte[] hashMsg;
protected AbstractSCCPasswordHash(byte[] hashMsg) {
this.hashMsg = hashMsg;
}
public abstract byte[] toBytes();
@Override
public abstract String toString();
public abstract boolean validatePasswordHash(PlaintextContainerInterface password) throws SCCException;
public abstract boolean validatePasswordHash(byte[] password) throws SCCException;
}
abstract class AbstractSCCSignature {
byte[] signatureMsg;
protected AbstractSCCSignature(byte[] signatureMasg) {
this.signatureMsg = signatureMasg;
}
public abstract byte[] toBytes();
@Override
public abstract String toString();
public abstract boolean validateSignature(AbstractSCCKey key) throws SCCException;
public abstract AbstractSCCSignature updateSignature(PlaintextContainerInterface plaintext, AbstractSCCKey key)
throws SCCException;
}