Is there any way to make XAdES signature using Google Cloud KMS? I cannot find any info about it.
Wow, XAdES is a maze of twisty standards documents, it's tough to find what is supported. From what I can tell, XMLDSIG originally supported DSA and RSA-SHA1 which are now pretty dated and neither is supported by Cloud KMS's algorithms.
In 2013 XML Signature Syntax and Processing Version 1.1 which specified some more algorithms, including an RSA algorithm with SHA-256 which should be compatible with Cloud KMS's RSA_SIGN_PKCS1_2048_SHA256, RSA_SIGN_PKCS1_3072_SHA256 and RSA_SIGN_PKCS1_4096_SHA256. and I believe its ECDSAwithSHA384 should be compatible with Cloud KMS's EC_SIGN_P384_SHA384.
There may have been further developments since then with other supported algorithms. I suspect that particular XAdES implementations or interoperability groups may only support a selection of algorithms, so you may need to check with those for interoperable algorithms.
All that said, Cloud KMS does not provide the tooling to encode the documents for signing nor encode the signatures in a way compatible with XAdES, so while I believe, if you had algorithmic compatibility, you could implement signing with keys stored in Cloud KMS, but it would take a chunk of work to do the various format conversions.
Thanks for using GCP and Cloud KMS. If you have more info on what you wish it could do, I'd be happy to get the request.
Related
My application has to publish a file to several clients over a common channel. I have been doing below process to encrypt it
Generating a symmetric key to encrypt the data.
then encrypting this key with RSA public key and publish it.
Considering all the clients of this application have application's RSA public key, is there any standard format to encrypt a file before publishing it?
Apparently, there are several standard formats for encryption. One of the most popular standard format is Cryptographic Message Syntax (CMS). Also refer to specs for CMS at Internet Standard. This format is widely used for for S/MIME mail message security.
Bouncy Castle APIs provides a wonderful support for this. BC's bcmail-jdkNN-MMM.jar is the Bouncy Castle SMIME/CMS library which is of your use. It is a package for processing RFC 3852 Cryptographic Message Syntax (CMS) objects - also referred to as PKCS#7 (formerly RFC 2630, 3369), and also dealing with S/MIME objects (RFC 3851).
Another popular standard format, XML Encryption format. end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications.
I have just watched a crypto 101 talk which said if you are typing the letters "AES" into your code, you're doing it wrong! The solution was to "just use GPG".
If you are storing your data on the cloud, all readers and writers need to know the key. If the key is a public private key, that's just a slow key but not a more secure key than just having a good password?
What standard alternatives are there to GPG that properly encrypt data at rest but use a shared secret instead of public keys?
I use Java, and would like to use a library, but want interchange with other platforms.
The solution is wrong in terms - you don't use "GPG" but OpenPGP.
Indeed for encryption using shared secrets (passphrases and alike) OpenPGP is optimal, as it supports multiple methods at the same time and includes compression.
The alternative would be to use CMS encryption with keypairs derived (in some predetermined way) from the shared secret. However such scheme is not standard.
I can remember also XML encryption that supports encryption with symmetric keys, but it has certain security flaws.
So OpenPGP is probably the best way to go.
Regarding compatibility - OpenPGP-compliant library should create packets that can be later processed by any other OpenPGP-compliant library or application. Unfortunately OpenPGP implementation in popular BouncyCastle library sometimes produces not compliant packets - we came across its issues several times when packets created with BouncyCastle could not be processed by GnuPG or our SecureBlackbox due to issues in the packet created.
I am looking for a good library that can perform pairing based cryptography (PBC).
One I could find is jPBC
What have others used? and their experiences?
The idea is to test the performance of algorithms using standard pairings (Weil, Tate) as well as some of the newer proposals without getting my hands too much dirty in the math.
I do work in this space as well. The best thing we could find in java was jPBC. Its not very good.
Non java alternatives:
MIRACL: I believe this is the current
fastest c implementation.
charm crypto: a python framework for
rapidly prototyping crypto systems. Full disclosure, I am a dev on
it. It has bindings to some subset of MIRACL and Lynn's PBC lib.
These are more than enough to impliment most schemes.These subsets
are expanding and probably can be readily expanded without getting
into the math involved. Given specific requests, we might even be willing to do those
extensions
Furthermore, it already has support for benchmarking that can
give specific time spent in cryptographic operations, the number of operations (e.g.
pairings and exponentiations), and other stats.
An open-source java implementation of Miracl is at
https://dsl-external.bbn.com/tracsvr/openP3S/wiki/jmiracl
Includes benchmarks
MIRACL is the gold standard for Elliptic Curve Cryptography over GF(p) and GF(2m) and additionally supports even more esoteric Elliptic Curves and Lucas function-based schemes. It also includes over twenty protocols based on the new paradigm of Pairing-Based Cryptography. Using MIRACL means that AES encryption, RSA public key cryptography, Diffie-Hellman Key exchange and DSA digital signature are all just a few procedure calls away.
You can read more about MIRACL here and download the SDK: https://github.com/miracl/MIRACL
I`m searching if there is how to execute the XML-Enc specification http://en.wikipedia.org/wiki/XML_Encryption without use of external APIs like Apache Santuario.
Thanks in advance!
Nope, there is no internal XML encryption library, because the JSR-106 has been withdrawn. So you have to use a external API. Unfortunately the Santuario API is not as clean as most API's that are included in the Java runtime.
http://www.jcp.org/en/jsr/detail?id=106
PS when using any XML encryption library, be sure to verify the content before decrypting, or you will have problems with e.g. padding oracle attacks (this warning is in the W3C XML encryption specification, but it is ignored all to often).
I am currently upgrading an application that generates OpenPGP messages to be FIPS 140-2 compliant. Currently I generate PGP messages that use RSA/AES-256 encryption which are both approved algorithms using BouncyCastle and its OpenPGP provider. I am no longer able to use BouncyCastly since it is not FIPS 140-2 validates, so I am looking at the BSAFE library from RSA.
This library doesn't have the high-level abstraction to let you generate an OpenPGP message directly. Does anyone know of a library that can use an existing JCE provider (like my BSAFE library) capable of generating OpenPGP messages? I'd really like to avoid having to implement the OpenPGP spec myself, as that seems like it would be quite time consuming. Alternatively any suggestions for other ways to format my encrypted files?
Thanks in advance for any input!
After much research it seems that there is no way to do this without implementing the OpenPGP format yourself. However the Cryptographic Message Syntax seems to be a suitable replacement.
There are major differences between S/MIME (Cryptographic Message Syntax) and OpenPGP.
http://mozilla-enigmail.org/forum/viewtopic.php?t=67
Mainly, S/MIME exchanges keys in terms of certificates (which must utilize a certificate authority, limited to 1024 bit, and expires after 1 year), while OpenPGP uses PGP keys (can be exchanged peer-to-peer, or utilize a free keyserver, or host your own keyserver).
FIPS 140-2 doesn't apply to protocols like SSL, PGP, S/MIME, or SSH. Those are security protocols that use cryptographic algorithms like RSA and AES. (Commercial crypto vendors aren't likely to point out this distinction, however).
FIPS 140-2 lists approved algorithms. It also specifies testing criteria for "cryptographic modules" that implement these algorithms. But, it doesn't say anything about the application of these algorithms.
So, you can use BouncyCastle's PGP provider. Instead of installing Bouncy Castle as a crypto-provider, install your FIPS 140-2–certified implementation. Bouncy Castle's PGP will use the preferred crypto provider for its underlying cryptographic algorithms. You can use their S/MIME support in the same way.