Giter VIP home page Giter VIP logo

mastercard / client-encryption-java Goto Github PK

View Code? Open in Web Editor NEW
98.0 19.0 58.0 549 KB

Library for Mastercard API compliant payload encryption/decryption.

Home Page: https://developer.mastercard.com/platform/documentation/security-and-authentication/securing-sensitive-data-using-payload-encryption/

License: MIT License

Java 100.00%
java field-level-encryption fle encryption decryption openapi mastercard jwe

client-encryption-java's People

Contributors

arankin-irl avatar danny-gallagher avatar dependabot[bot] avatar ech0s7r avatar fangpenlin avatar geekypandey avatar j256 avatar jaaufauvre avatar joseph-neeraj avatar karen-avetisyan-mc avatar nehasony avatar rfeelin avatar rossphelan avatar shilpat55 avatar shimonar-mc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

client-encryption-java's Issues

[BUG] Update README to reflect the correct class for JWE configuration object

Bug Report Checklist

  • Have you provided a code sample to reproduce the issue?
  • Have you tested with the latest release to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?

Description
We are trying to use the new JWE Encryption with our Send 2.0 Implementation.
The README for this library states to pass an EncryptionConfig instance, but the JweEncryption.encryptPayload method actually requires us to pass an JweConfig instance.

To Reproduce

  1. Add client-encryption dependency in your project.
  2. Create JWE Encryption configuration as mentioned in the README
  3. Pass this Encryption config instance to the JweEncryption.encryptPayload method with the request payload.
  4. IDE throws the error "The method encryptPayload(String, JweConfig) in the type JweEncryption is not applicable for the arguments (String, EncryptionConfig)"

Expected behavior
The documentation should be updated to reflect the correct class for JWE configuration object.

Screenshots
README documentation states to use instance of EncryptionConfig:
Screenshot 2021-06-07 at 12 59 36 PM

JweEncryption.encryptPayload method requires instance of JweConfig:
Screenshot 2021-06-07 at 1 00 02 PM

[REQ] Support A128GCM and other A GCM encryption method

Is your feature request related to a problem? Please describe.

While trying to implement network token checkout API as described here:

https://developer.mastercard.com/src/documentation/integration/server_integration/checkout/

We realized that the response payload coming from the MasterCard sandbox API server is using A128GCM algorithm for encryptedPayload encryption.

And currently that doesn't seem to be supported by this library, we got an error raised from here

throw new EncryptionException(String.format("Encryption method %s not supported", encryptionMethod));

Describe the solution you'd like

Support A128GCM and other A-GCM encryption methods

Describe alternatives you've considered

N/A

Additional context

N/A

[BUG] Can not decrypt JSON array over JWE entire payload mode

Bug Report Checklist

  • Have you provided a code sample to reproduce the issue?
  • Have you tested with the latest release to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?

Description
I can't decrypt simple JSON array or JSON array consisted of objects over the JWE entire payload mode (I had encrypted it before decryption process in my own). The decryption process throws an exception: com.jayway.jsonpath.PathNotFoundException.
I mean arrays like below:

["abcd", "efgh"]

or

[
  {
    "field": "abcd"
  },
  {
    "field": "efgh"
  }
]

The exception stacktrace:

com.mastercard.developer.encryption.EncryptionException: Payload decryption failed!

	at com.mastercard.developer.encryption.JweEncryption.decryptPayload(JweEncryption.java:58)
	at com.example.EncryptionTestUtil.decrypt(EncryptionTestUtil.java:31)
	at com.example.EncryptionTestUtil.test1(EncryptionTestUtil.java:56)<31 internal lines>
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) <9 internal lines>
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) <23 internal lines>

Caused by: com.jayway.jsonpath.PathNotFoundException: Expected to find an object with property ['encryptedValue'] in path $ but found 'java.util.ArrayList'. This is not a json object according to the JsonProvider: 'com.jayway.jsonpath.spi.json.JacksonJsonProvider'.
	at com.jayway.jsonpath.internal.path.PropertyPathToken.evaluate(PropertyPathToken.java:71)
	at com.jayway.jsonpath.internal.path.RootPathToken.evaluate(RootPathToken.java:62)
	at com.jayway.jsonpath.internal.path.CompiledPath.evaluate(CompiledPath.java:99)
	at com.jayway.jsonpath.JsonPath.delete(JsonPath.java:258)
	at com.jayway.jsonpath.internal.JsonContext.delete(JsonContext.java:160)
	at com.jayway.jsonpath.internal.JsonContext.delete(JsonContext.java:155)
	at com.mastercard.developer.encryption.JweEncryption.decryptPayloadPath(JweEncryption.java:118)
	at com.mastercard.developer.encryption.JweEncryption.decryptPayload(JweEncryption.java:52)
	... 67 more

To Reproduce
Code snippet:

 public static String decrypt(String value) throws Exception {
    var config =
        JweConfigBuilder.aJweEncryptionConfig()
            .withDecryptionPath("$.encryptedValue", "$")
            .withDecryptionKey(CertificateTestFactory.createPrivateKey())
            .build();

    return JweEncryption.decryptPayload(value, config);
  }

  @Test
  void test1() throws Exception {
    String objectArray = "[{\"field\":\"abcd\"}, {\"field\":\"efgh\"}]";
    String stringArray = "[\"abcd\", \"efgh\"]";

    JweConfig jweConfig = prepareConfigurationForEntireResponseEncryption(CertificateTestFactory.createEncryptionCertificate());

    String encryptedStringArray = JweEncryption.encryptPayload(stringArray, jweConfig);
    System.out.println("encryptedStringArray: " + encryptedStringArray);
    System.out.println("decryptedStringArray: " + decrypt(encryptedStringArray));


    String encryptedObjectArray = JweEncryption.encryptPayload(objectArray, jweConfig);
    System.out.println("encryptedObjectArray: " + encryptedObjectArray);
    System.out.println("decryptedObjectArray: " + decrypt(encryptedObjectArray));
  }

  private JweConfig prepareConfigurationForEntireResponseEncryption(Certificate certificate)
          throws EncryptionException {
    return JweConfigBuilder.aJweEncryptionConfig()
            .withEncryptionCertificate(certificate)
            .withEncryptionPath("$", "$")
            .withEncryptedValueFieldName("encryptedValue")
            .build();
  }

Expected behavior
Getting a value encrypted before.

Additional context
The configuration is prepared in compliance with https://github.com/Mastercard/client-encryption-java#encrypting-entire-payloads-jwe

[REQ] request to add overloaded public methods in EncryptionUtils to take InputStream as parameter

Inside the EncryptionUtils class all the public methods that load encryption cert or keys now only take file path as parameter.

It would be great to add corresponding overloaded methods that are able to load keys from the input stream. The use case for this request is that the encryption key and cert in our case are stored in Vault. Upon application starting up, it will retrieve the key and cert from Vault and load them into memory. We want to avoid creating a physical file for the key and cert and instead use input stream.

"Sonar Check" CI build step fails

Description
The Sonar Check CI build step fails because the Java version used is no longer supported. I'd suggest bumping it to 17 or newer, as stated in the error message below (taken from the latest workflow run):

Error:  Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.10.0.2594:sonar (default-cli) on project client-encryption: 
Error:  
Error:  The version of Java (11.0.22) used to run this analysis is deprecated, and SonarCloud no longer supports it. Please upgrade to Java 17 or later.

To reproduce
Push a commit (branch doesn't matter), or check the last few commits.

Expected behavior
The SonarQube scanner plugin for maven can be executed successfully, allowing the "Sonar Check" build step to succeed.

Suggest a fix/enhancement
Bumping the Java version used for executing the plugin to 17 should fix the issue.

Example of certificate fingerprint is unclear

We have done client implementation encryption for instance provisioning, not in java but in go. we use all test sample and test case to verify our implementation. Everything went well until we hit api. Failed on first step: Fingerprint verification. The fact is the fingerprint is for public certificate, not for key. The term "Pulbickey fingerprint" is confused. Mastercard api require fingerprint is for certificate, not for the public key generated from certificate. It would be good on documentation comments it out or example for that.

[REQ] add maven wrapper functionality

Is your feature request related to a problem? Please describe.

I am always frustrated when I need to select a specific version of maven/gradle for the project.
Even if the project builds, I still want to use the very same version as the one it was created with.

Describe the solution you'd like

Utilize "maven wrapper" functionality, similar to the "Gradle wrapper" one.

Describe alternatives you've considered

We could move to gradle and use gradle's wrapper, but I prefer incremental and simple solutions.

Additional context

https://maven.apache.org/wrapper/

[BUG] Service Configurations for Client Encryption Java MDES Token Connect - missing Push Multiple Accounts configuration

Bug Report Checklist

  • Have you provided a code sample to reproduce the issue?
  • Have you tested with the latest release to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?

Description
In the "Service Configurations for Client Encryption Java", the section "MDES Token Connect" misses the Encryption Path for the new Push Multiple Accounts payload. Using the default config results in an INVALID_JSON error.

To Reproduce
Use the provided FieldLevelEncryptionConfigBuilder for the MDES Token Connect.

Expected behavior
The payload is correctly encrypted.

Suggest a fix/enhancement
Add
.withEncryptionPath("$.pushFundingAccounts.encryptedPayload.encryptedData", "$.pushFundingAccounts.encryptedPayload")
to the provided config, optionally mark
.withEncryptionPath("$.pushFundingAccount.encryptedPayload.encryptedData", "$.pushFundingAccount.encryptedPayload")
as obsolete (or remove it altogether).

[REQ] Support json path wildcards

Is your feature request related to a problem? Please describe.

Imagine a scenario in which there are multiple values that need to be encrypted/decrypted within a json list. The list can have an arbitrary number of items. It is impossible to specify an encryption path that matches each of these items. When I try this, I get java.lang.IllegalArgumentException: JSON paths for encryption must point to a single item!

{
  "items": [
    {
      "value": "foo1",
      ...
    },
    {
      "value": "foo2",
      ...
    },
    ...
  ] 
}

Describe the solution you'd like

We should be able to specify an encryptionPath with a wildcard such as $.items[*].value

Describe alternatives you've considered

Workaround we will use is to encrypt the entire list, although we'd prefer to only encrypt the necessary attribute.

Additional context

n/a

[BUG] Encryption key requires decryption key

Bug Report Checklist

  • Have you provided a code sample to reproduce the issue?
  • Have you tested with the latest release to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?

Description
I'm running into an issue in the JWEConfigBuilder where either the decryptionKey or encryptionCertificate is required. I want to use an encryptionKey instead of encryptionCertificate, and I don't want to be forced to provide a decryptionKey. Please correct me if I'm wrong, but I assume this was just a minor oversight in #60.

To Reproduce

  1. Use the JWEConfigBuilder to create a JWEConfig with an encryptionKey and no decryptionKey.
  2. IllegalArgumentException("You must include at least an encryption certificate or a decryption key") is thrown

Expected behavior
The JWEConfig can be built without any exceptions being thrown, and the config can be used to perform encryption.

Sample failing code

val jweConfig = JweConfigBuilder
            .aJweEncryptionConfig()
            .withEncryptionKey(publicKey)
            .withEncryptionPath("$", "$")
            .withEncryptedValueFieldName("encryptedPayload")
            .build()

Additional context
I'm using this library in an Android app that makes calls to middleware, which makes the calls to Mastercard APIs. I want to avoid worrying about managing the private key in my app, which is why I'd like to see this resolved. In the meantime I plan on using an empty implementation of the PrivateKey interface, but I'd like to avoid that if possible.

Related issues/PRs
Has a similar issue/PR been reported/opened before? No, but it seems related to #60

Suggest a fix/enhancement
Changing the implementation of checkParameterValues in JweConfigBuilder should fix this issue.

private void checkParameterValues() {
        if (decryptionKey == null && encryptionCertificate == null && encryptionKey) {
            throw new IllegalArgumentException("You must include at least an encryption certificate, an encryption key, or a decryption key");
        }
    }

Problem on response decryption

Hi,
I'm getting decryption error when trying to decrypt MDES response.
From the code snippet I can clearly see that if params == null, params.getSecretKey() is always null, and decryption error on AESCBC.cipher is inevitable.
Is this code part correct?

if (params == null) {
// Read encryption params from the payload
Object oaepDigestAlgorithmJsonElement = readAndDeleteJsonKey(payloadContext, jsonPathIn, inJsonObject, config.oaepPaddingDigestAlgorithmFieldName);
String oaepDigestAlgorithm = JsonParser.jsonEngine.isNullOrEmptyJson(oaepDigestAlgorithmJsonElement) ? config.oaepPaddingDigestAlgorithm : JsonParser.jsonEngine.toJsonString(oaepDigestAlgorithmJsonElement);
Object encryptedKeyJsonElement = readAndDeleteJsonKey(payloadContext, jsonPathIn, inJsonObject, config.encryptedKeyFieldName);
Object ivJsonElement = readAndDeleteJsonKey(payloadContext, jsonPathIn, inJsonObject, config.ivFieldName);
readAndDeleteJsonKey(payloadContext, jsonPathIn, inJsonObject, config.encryptionCertificateFingerprintFieldName);
readAndDeleteJsonKey(payloadContext, jsonPathIn, inJsonObject, config.encryptionKeyFingerprintFieldName);
params = new FieldLevelEncryptionParams(JsonParser.jsonEngine.toJsonString(ivJsonElement), JsonParser.jsonEngine.toJsonString(encryptedKeyJsonElement), oaepDigestAlgorithm, config);
}
// Decrypt data
byte[] encryptedValueBytes = decodeValue(JsonParser.jsonEngine.toJsonString(encryptedValueJsonElement), config.fieldValueEncoding);
byte[] decryptedValueBytes = AESCBC.cipher(params.getSecretKey(), params.getIvSpec(), encryptedValueBytes, Cipher.DECRYPT_MODE);

[REQ] Make it possible to set encryption public key directly without a certificate

Is your feature request related to a problem? Please describe.

While I was trying to use this library for encrypting request payload for MasterCard API, I realized that currently this library only supports taking a certificate as the source of encryption public key. Such as

JweConfig config = JweConfigBuilder.aJweEncryptionConfig()
    .withEncryptionCertificate(encryptionCertificate)
    // …
    .build();

However, when I was reading the MasterCard API documents, the public key provided in the URL like this 149123-src-fpan-encryption one here is in JWK format:

https://sandbox.src.mastercard.com/keys

but I cannot find a corresponding X.509 certificate file format for the key. I tried my best to see if I can convert the JWK format public key into a X.509 certificate file, but it appears that normal flow of creating a X.509 using CSR requires generating a key pair in the first place. There seems like no real easy way to convert the JWK key format into a X.509 certificate (other than maybe using very low level API of OpenSSL or study X.509 file format to fill in the data yourself).

As a result, we won't be able to take advantage of using this library if there's no certificate file but only JWK provided for encryption. I read through the code, and for now the certificate is only used for getting the public key from it.

Describe the solution you'd like

Then I wonder, why not just make it possible to take PublicKey object directly instead of a Certificate? In this way, I can easily convert the JWK into public PEM file and feed it into this library. We can provide a new function in the builder like this

JweConfig config = JweConfigBuilder.aJweEncryptionConfig()
    .withEncryptionKey(encryptionKey)
    // …
    .build();

To avoid breaking existing dependency on the original certificate method, we can keep it as is, but add extra check to avoid setting certificate and public key in the same time.

Describe alternatives you've considered

Thought about just change the builder to accept only RSA public key, but it would be a breaking change then. So maybe it's better to keep original certificate option.

Additional context

N/A

Add support for the IBM providers and the IBM J9 VM

The library is currently failing in an IBM/Websphere context where the default JCE providers are not available:

 Caused by: java.security.NoSuchProviderException: No such provider: SunJCE
       at javax.crypto.Cipher.getInstance(Unknown Source)
       at com.mastercard.developer.encryption.FieldLevelEncryptionParams.unwrapSecretKey(FieldLevelEncryptionParams.java:155)
       ... 49 more

Available providers

security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
security.provider.2=com.ibm.crypto.provider.IBMJCE
security.provider.3=com.ibm.security.jgss.IBMJGSSProvider
security.provider.4=com.ibm.security.cert.IBMCertPath
security.provider.5=com.ibm.security.sasl.IBMSASL
security.provider.6=com.ibm.xml.crypto.IBMXMLCryptoProvider
security.provider.7=com.ibm.xml.enc.IBMXMLEncProvider
security.provider.8=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
security.provider.9=sun.security.provider.Sun

Example of JVM:

Java               : 1.7
JVM vendor name    : IBM Corporation
JVM vendor version : 2.7
JVM name           : IBM J9 VM
JVM version        : pwa6470_27sr2-20141026_01 (SR2)
JVM info           : JRE 1.7.0 Windows amd64-64 Compressed References 20141017_217728 (JIT enabled, AOT enabled)
J9VM - R27_Java727_SR2_20141017_1632_B217728
JIT  - tr.r13.java_20141003_74587.01
GC   - R27_Java727_SR2_20141017_1632_B217728_CMPRSS
J9CL - 20141017_217728
OS name            : Windows
OS version         : 6.3

[REQ] add Gradle Enterprise Exce

Is your feature request related to a problem? Please describe.

Gradle Enterprise Plugin offers a "scan" functionality, which allows analyzing how the project is built and such.

It also exercises the "cache" technology, which speeds up the builds by not running the tasks which had no inputs/outputs changed.

Describe the solution you'd like

add gradle-enterprise-maven-extension

Describe alternatives you've considered

Using 3rd party analytical tool + breaking the project into microprojects, so they are released separately.
1st one is an overkill and 2nd is a waste of developers' time.

Additional context

https://docs.gradle.com/enterprise/maven-extension/#:~:text=You%20apply%20the%20Gradle%20Enterprise,once%20you%20run%20your%20build.

[REQ] InputStream param for loadDecryptionKey(), loadEncryptionCertificate()

Is your feature request related to a problem?

In method EncryptionUtils.loadDecryptionKey(decryptionKeyPath)
decryptionKeyPath path is required, this do not work when project is packaged in JAR.
I package Spring boot project with maven in to JAR and run in on docker.

Describe the solution you'd like

Maybe you can add additional method with InputStream param:
EncryptionUtils.loadDecryptionKey(InputStream decryptionKeyInputStream)
As you have it in AuthenticationUtils.loadSigningKey(InputStream pkcs12KeyInputStream)
also please do the same with EncryptionUtils.loadEncryptionCertificate(certificatePath).

Describe alternatives you've considered

Currently I did work around overriding your existing methods impl.

[REQ] Patching vulnerable dependencies

Is your feature request related to a problem? Please describe.

I've discovered a few vulnerable dependecies in test scope:

  • org.codehaus.jettison:jettison 1.4.1
  • net.minidev:json-smart 2.48
  • com.fasterxml.jackson.core:jackson-databind 2.13.2.2

Describe the solution you'd like

Upgrade mentioned dependencies to latest version

Describe alternatives you've considered

Consider replacing vulnerable artifacts with alternatives.

Additional context

[BUG] Can't set JSON engine in JsonParser

Bug Report Checklist

  • Have you provided a code sample to reproduce the issue?
  • Have you tested with the latest release to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?

Description
The README says we should be able to set a specific JsonEngine in the JsonParser class. However, in the latest released version 1.7.1, the JsonParser class is package-private and the method withJsonEngine is also package-private.

To Reproduce
Add the documented call

JsonParser.withJsonEngine(new JettisonJsonEngine());

to any static block in a class. The call does not resolve.

Expected behavior
Should be able to change the JsonEngine. We'd like this feature because we want to ensure the same JsonEngine is selected regardless of other dependencies we may include on our classpath.

Screenshots
N/A

Additional context

Related issues/PRs
Has a similar issue/PR been reported/opened before?

Suggest a fix/enhancement
Make JsonParser public and the withJsonEngine method public

java.lang.IllegalArgumentException: JSON object expected at path: 'addressRequest.country'!

Trying to decrypt with same source and target json path but getting an illegal argument exception stating an object is expected.

I am getting this error for the path:

$.addressRequest.country

The error I am getting is:

   Exception in thread "main" java.lang.IllegalArgumentException: JSON object expected at path: '$.addressRequest.country'!
	at com.mastercard.developer.encryption.FieldLevelEncryption.readJsonObject(FieldLevelEncryption.java:282)
	at com.mastercard.developer.encryption.FieldLevelEncryption.decryptPayloadPath(FieldLevelEncryption.java:227)
	at com.mastercard.developer.encryption.FieldLevelEncryption.decryptPayload(FieldLevelEncryption.java:118)
	at com.mastercard.developer.encryption.FieldLevelEncryption.decryptPayload(FieldLevelEncryption.java:98)

The FieldLevelEncryption configuration I am using is:

            FieldLevelEncryptionConfig decryptionConfig = FieldLevelEncryptionConfigBuilder
                    .aFieldLevelEncryptionConfig()
                    .withDecryptionKey((PrivateKey) doantetestrsa2048)
                    .withDecryptionPath("$.addressRequest.encryptedFields.dEnum", "$.addressRequest.encryptedFields.decryptedDEnum")
                    .withDecryptionPath("$.addressRequest.encryptedFields.theField", "$.addressRequest.encryptedFields.decryptedTheField")
                    .withDecryptionPath("$.addressRequest.addressLine1", "$.addressRequest.decryptedAddressLine1")
                    .withDecryptionPath("$.addressRequest.addressLine2", "$.addressRequest.decryptedAddressLine2")
                    .withDecryptionPath("$.addressRequest.country", "$.addressRequest.country")
                    .withDecryptionPath("$.addressRequest.phoneNumber", "$.addressRequest.decryptedPhoneNumber")
                    .withDecryptionPath("$.username", "$.decryptedUsername")
                    .withDecryptionPath("$.cardNumber", "$.decryptedCardNumber")
                    .withDecryptionPath("$.theEmail", "$.decryptedTheEmail")
                    .withOaepPaddingDigestAlgorithm("SHA-256")
                    .withEncryptedValueFieldName("encryptedValue")
                    .withEncryptedKeyFieldName("encryptedKey")
                    .withOaepPaddingDigestAlgorithmFieldName("oaepPaddingDigestAlgorithm")
                    .withIvFieldName("iv")
                    .withEncryptionCertificateFingerprintFieldName("publicKeyFingerprint")
                    .withFieldValueEncoding(FieldLevelEncryptionConfig.FieldValueEncoding.BASE64)
                    .build();

The payload I am trying to decrypt is:

{"someBoolean":false,"integer":123,"someLong":21345,"myEnum":"ABC","requestId":"f433b1e5-5708-4cb7-a92d-47a5333877dd","theDate":1565173764565,"addressRequest":{"encryptedFields":{"dEnum":{"encryptedValue":"eo09WDfmFyM8X0qBXyc0Jw==","iv":"OOlEyHunYljpetQgn6dBJw==","encryptedKey":"Rypv+giqbuvP5EG9j57OYPa9ZPaDlMpMaevTGEEm6nsC3QaxMWgfNfzSKmVZ6TTHLxDQEiNc8TojATH+pfnoPp+5C+zgWxJhcYO0Ge78SqmUjmIVNjR+wC8vImFVYQ5Ly2wFcyxEf7aLI6FSt245IDLzqzptd6qpOJwrp/mTS90kCQSGl5twIQIKeBVT82+dg25dZmXvSjZCFZNDasvsWgwIiVYoALT6EDP03HBrDUyKorbEWQ1U5U27B2fI4XD0YsM20Qi97wHZIca+He0ZhmRyiah148LEwKBmtA835EPO7SgLaLs3TPeUVxetAMXg5emKKwu0fcdN1Etevhc5wA==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"theField":{"encryptedValue":"Z/TZiRTUfuH+A57gqDJ9ig==","iv":"4aheHqWC93+lLTn5RktrHw==","encryptedKey":"ApM4s4YHJanO44fIYSH6Jow13bF6Uupz4YKJfCDynQ2gFoBnBaO/XiYBJfncvAdd5n2FvZVVWg2Gc75WtkFYKdCYHwuXn9/OdIiKF5EwWgsf9DtS3J3JypsQxTSsTdrjKCi3O+lm/G2Jlngt776498xfAE7H00bw6yss6XeUWQT7kZIqtClGaK0H8TW/G9z0ephfkLmAUi3q4HYnGj8lJoi/OG5DDtMgKuV3bqc+MqTta7Am/rYaEX72Qc2Jo8ag9aHC9DpKWfTUvQIK9XbLRd5jdP5zj2QE4KL2WACf6Cuc9mBD1rfJtCwNiGEZANN8RGpaPMxE/C3t6jcucEo+GQ==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"}},"addressLine1":{"encryptedValue":"5G8ZhB2v7CglfsaZNCRHxw==","iv":"aaauWh7AXAkb4t+daR3x1g==","encryptedKey":"e9NRLjYLokwXf3cJflkpl8hWu+XJIWwmm6ZuW01VWumtCz7ZuSMl/ngzOao0eatcgMCezil6ckGELruPUYoDxmVRBhy/oMao5q2gbwOwWJSZjGmqvN/U5Q8aFoBxKdgHDRX7oY+UMwOFMu9TRbQF7jHxBaDepThhUrPur3EcRMlGdW0wtIkqklaLxCECbUdiCtrKt6Hca9jPDWv1Q9TOlMerJkHwkafpNN2DOLWgPLSuCmN4UXpOpO5RQbFFkMWpcRQKVVl4h5qO6a3m3rLyv+U2+0rpRwcal4wNyJqUFm4RiRw4Nde13bprbpoPR22zIn+/NpjaFMjyDXCJ3HiOsw==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"addressLine2":{"encryptedValue":"JRiUwWK6USE4Ihul6LvhAA==","iv":"PNaFNYD5lqX3oYOg0CwMVg==","encryptedKey":"SA1oSfAwReifntnLdR4R3Wcuz9eC+u3Rl4ChbhW28mvS2evBl3/usPCFAYBRlITtn3PCKuMJ+mY6ZXPiLdNNJb8MKTvuEhHM2WA6yk/hi+6FzU6b9m51eyrNdH6Impq+ItlaHbqk1EZMlhIa8apimiK7AHhxtZJH+jzgcVYRLo1KMqQq+Xboma4NMENgJS/L9up4Ww+DYBcSVYfUwEVTz8044u7PFDFuXhL20MWHNSA/SJduT5CYAcQzfd1kXw9AnogBXKwe4XvC1rR8vmj/QnhBEPocJRzNvHgg0VlEs6OiNWUv8DUmsIpgvT7JQe6U29LgEqS+0gwdRPhM9J2law==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"country":{"encryptedValue":"Qiw1g87OCwa5/IXPC5nIJw==","iv":"OZt7FRV644fEFbb75VNdjA==","encryptedKey":"AyI8R1/ziGTZ6Uhy2JGsy+PYf+KXcrzn5v56tP3WnuFM2Qt24T9t4WXE+B1cqiDjo1LQIEgXJWZ5XX/fbYh/Y1qmycit/QmPVEjGqoKLNSB1Js00Cghyt7lChuSUIWRnYbNAa0q6EgPS5vyDrXDVZH0vkTM6egc7d76O9Sw+rXGzv9d9wiQlhxFXkb+GH/BCiswb064w53LcXdoBcup1sEEn6UIuORtiCGeQcNqS6yvkR3HWc0lrAJpCikJoTCMQli7MJYAVj+w4LZCUZMcwWMuiMhLQQdjTAhCCK9+fKItwA5xSDaXictspUALTi/drdcj2zXbxX3E2t+q1PgWPUg==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"phoneNumber":{"encryptedValue":"0UkGfBqglwNvRU058FgGvg==","iv":"3x97NgHgfSyHzvA5gopx9g==","encryptedKey":"Mm0CyOaKv32THaV4BKi+o2LHTSQPP3NVnvESJTDVGNLsjaOXjo3FrJaudeWCh6kvI5UM3ZD3sBbpqAh8Cs7ajXxB/tHGzZslbySExjSITbO3TWfOEkZZHy0Ac0BgGeCU9l3EtXt0UuIlOMKsg0AKrAw0i7zqTPtS0cJb+ghVns2GaQkWjc2ZFoC6rSlv1tLyg+vgRCcIT8tRS1WzLlW/gcXnbPEZOcRDA4909kfBQiWkPCuRcenP1wfs57jI+PBtDdOoKxhbnSP2I8jvwLByFcM2iy0O9+8GmubRGBNhYMuw+Ga8pTN8iVESpSwAuKZ1TOGg6QIwu2HQNE2lBly0ZA==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"}},"username":{"encryptedValue":"KSLbpdXPrwnGVsTCrZAH9BwmUIeLHRRHJFqZpSxvaeQ=","iv":"yNBeYiODdOouOIascnvutw==","encryptedKey":"bSUMfkSWPHzqmbqfmL/Uxg2hhLs4UT3NmK7UhAW3vlbhNj3623wHKjaj3/jrmR4OrYbjy483zwHEquC0ba3FvxuusNF7DWeQPlF6iAJgOuXNy7YXNuBi7qnJUJbjh6qa056f6CR0TC5qiDXaLdR0FfjQqT1iiVJic8chJXMka4ONxZK7RiaKeL7S8th7+IEj2BhervymcV+6dQFKUbwg5QrhaxzQc1yPuxAiHwlH0jEN8mvd6aR3jsX24rlY0YLUoax8b8Lnkg2KBQ7YUv54VYoCAIq1RkmG6YayfH8uhrAPqVf++jEKbtzGxsxDFeSqheHAvLoWENHelcioG/+6ww==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"cardNumber":{"encryptedValue":"blABJpAp73oWVuoOQgBcmsCmwYChPKeXc9NGCigq5eM=","iv":"oNCXpYTaokWTZoh//5ZnQQ==","encryptedKey":"ZAGxVnWrxwd7ht2Uf6IxGsbFByyu7P7xKRwKXs8lEu9uKnhdM4WyCQ7q4fRdtEN2GnTqn6OzfM0QP6eFRTfDt5PEQ3ieNZlKeRfQrG2F1VyB17FCBiBid5dBbR4p28dpBmZuTun6fTxnou2NOud2B8A7VHA8BhQVglj7SzEiJntVJc15sCvNt9Q4N0tBjqG1oTr+grntrnoI0WWNNMtXEGOavRCaYrRNJmEmc65Uyl6zSh8TcThXGAZFuUZR+h84vg1o53AoIcHP783uHkOOfy5+joqz2x11cCjC/pI+aCWWvkIfLjKzwqIx9BYOdgu19+DbHR5JLLJRp257BCG59A==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"},"theEmail":{"encryptedValue":"m9zN9aiwNs4pi03Kyms7T9+Gg18cpuDPD/AsqK+70nY=","iv":"WdNKVYPrAOLqqzskmZIIDw==","encryptedKey":"Ejfj9cv/q8yjIyOyd59n4igmTwU4RIKWdNv/sQV1R3NGTWuGxcbpGqHt6X1+hNc06MM1WmtkLUh9yv1ZNoq/76xvYa5De1iCn/HU4JMx/NPvVRZge9SmuQ9EXmM70P3btgVg5VM33lzgGkRuhWu/+HNHG0h9KXsTPnqHw6bUfk6Uws91gi78Ucl2WCskQn8k4igA93zKozvQzhCfmkPzxPEIbcFAjBgIAyV1Ugnpmx4TZ78DyWKilZ28jc454I+hVLBGJEohrjRmHOUVpOyr8zn3qwOtzMsUS/4mHGgbi1tMXM1kcU0BqLYEtsWGsWqkJtYrCWkIimSDVM1XI6AcMw==","publicKeyFingerprint":"29f8a7cea970886829226864c79195088ee464a89d8bc835d392c1f6666326c6","oaepPaddingDigestAlgorithm":"SHA256"}}

The base64 encoded RSA private key (using a self signed RSA cert) is:

MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQClPNgGKUEUSZ5CUGQ5tEw9ZeYLPv6+vMZ6YH7QfzhCQwas1nL+eTsXAooggd0HglICSsIYcHMvnUuD458G3j8NGBTcuzO0FKsc+9WjWKXyqfvi9SnM/1q8ZvyIRbw2a1bSpND63d2GVERoK/31cyesb7BS4Jr/EQCEK+kN87l9MMkPmgAFBCAXrQ+ZdiZ43j0Czs6c7a+ueRRAfChKjS5nrUpFc/MWWPCUKUmqMnJMRaCTvQ+9ZIbnBccs2grbP9F+V25EpVagcbbE/c5RXzqbUNIUK/BpeJ9IPE7ZvUu8cEQU1pJIlk8TLnoIFyJwdRF9FDT/iNsHxuBNjpwT5EExAgMBAAECggEBAJWjciayOYN739xCHWG8i8aWfyv0EpL9NekhdfavH22ycVsYoe8eLor5+8jQki/4rvfwZ7HmNAoMspRwEFYR8puTEWGMDpiolwWacrCI2U/W7ItuZjqFjdBMm6l1LatCrc/4/mARiEncCk8kd8pOTMF2LAIB8ZvH8+W+NkIyU+qwTMyHFzpG1XE1/QQgr3sEHsOnBkyWZteS42AYa11lPA2Agt5OpABi6cgTVsfUdmlrpaAuP00fmWXdFBzZRKHBTJHamFrp2Bm/i3+YQMdwMtbOKGo4R2VuTVcMaYb7jocGQ/goEHonOeV5SoeIdb3DfC0qlazhAM9Za2MsL2aD15kCgYEA1JYwb5l0WDFI0kHI4js/TQOc5p45jseQjYblouc0UccUZDjq26v5gDM+/xbo3Wv25p6Wkxn0HuCWzw+1hoOGKsX9U8846H+b/G9F2ihMj2a9oYFedNY0f2MYEbpKRehMNTARIOriQ/lXh/RTyr6jDD4wxH90KuuYhRVNnfcPnK8CgYEAxvtMO+6enIzW3OCRaY+9sWSqBp8orc2vSsO3ekt5ZVU4+crK+RIXRnCB8lOtPu2RD9jAYeXpyqqJ8f03slGtmSUshLv2xg3kWEuKP1XrXSnArqKWMf1v9DhvLV1Do07nwKw2wMQc+rufD65IJ7Yg5T7/TxmFyVeIS8rga/9mOB8CgYBBGjV/F7l/gKhSa37/eTFrfl3AalgqF4d3MAaHGtL08EiYYK3b1BC2Z/s012k81eFowsxOBDa0dgb5JlBq/0BJPRTVY7KD0QCOD+2OX6UCjW4pVZr9oNO25zvpwekY+4jLCQtVz1i3hFZ/9hzrC/KWvzzkEDwdIMU2jE2WwKBxVQKBgFKT69lbeBvEH09fKznB25mJCz7gQoOOvtaqTrTEKccyDQktbfrb1Sj4fBVTQKzC7tbCv2RhhBsFl2YEDl9EomTSFp2nXAxpq4AxKViLkbgCIeLXurlYUmPqH8mV0QIvNuKxFa/+M4Ci6KobS/qfDRvWfyIWl30thHTf5y8quQNFAoGBALYIgy7b9JjGp2BwITMK1AFhH40Kl2C6Myk2ikITxNtKAYucDE27+OHmXSUvmi2itC0SpthTNt0nd5KAm7490WQdwU8xD+t3vb879gRJx4LZT/FjI+u3U8+Q4kKyUHpLDQuPhTYA6B2LA1LBlQlNmyHZ4rfXarq79sN+UG4h2lCv

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.