I'm testing a system which involves updating a database using files sent from external parties. These files sent from external parties are basically just large flat files to update a database. The requirement is that these files must be signed used a File Signing Key in accordance with the FIPS 186-4 Digital Signature Standard using SHA-256 hashing algorithm and encrypting the derived hash using an RSA Digital Signing Algorithm of 2048-bit modulus in accordance with PKCS #1. The SHA-256 hashing algorithm will be applied to the entire data file. This will result in a digital signature of 2048 bits in Octet form, which will be appended within the file.

To test that the system verifies the signature correctly, I need to firstly sign the file. Information Security is not really my forte and I would appreciate guidance in the right direction. Is there a tool that I can use to perform this? Apart from the certificates, what would the pre-requisites be?

Many thanks.

1 Answer 1


The text you quote basically means: the file is signed with RSA, and the signature is appended "as is" to the file. There is nothing about certificates here; signatures use keys. Certificates are ways to bind public keys to identities. The passage you quote, though atrocious in many ways, is still relatively clear about the certificates: there are none here.

Signatures make sense only relatively to verification:

  • The signature is produced with, as inputs, the data to sign (the entire file) and the private key.
  • The verification takes as input the signed data (the entire file, again), the signature, and the public key, and tells you whether the signature is good or not.

As you describe the problem, the database expects input files to be signed with a specific private key, corresponding to the public key that the database will use for the verification. If you do not have that private key at hand, then you will not be able to generate signatures. You need that key if you want to sign a file of your own. Otherwise, that's an absolute no-way.

If you have the private key in some format or another, you will still need to write a little piece of code to compute the signature and append it to the file (this simple "appending" process is not a standard signature format, so you won't get a standalone off-the-shelf tool to do it). This can be done in many programming frameworks, e.g. with Java (using java.security.Signature) or C (with some library like OpenSSL).

Anyway, in cryptography, you can do no decent testing "from the outside". The best you can do is to take an existing signed update file, that the database accepts; then modify the signature (change the value of one of the bytes of the signature, which should be the last 256 bytes of the signed file, from your description), and see that the file with the modified signature is no longer accepted by the database. This would demonstrate that the database "verifies something", not that it does it correctly. Knowing whether a cryptographic system does its job adequately is not done by testing but by auditing the code.

  • For this specific (and rather inflexible) case, commandline openssl rsautl can generate a raw RSA signature, and pretty much any OS can append with >>file or at least concatenate files. +1 to everything else. Commented Jul 15, 2014 at 15:17
  • Thanks very much for your detailed answer Thomas. Very Helpful. Regarding Certificates, they will be required as the header of the data file will contain a Company ID that identifies the Org that sent the data. The system will use this to get the Certificate for the Company, from the Certificate Store, to obtain the Public Key. Will this cause much changes?
    – fdama
    Commented Jul 16, 2014 at 8:29
  • Clarification: I should have said rsautl produces a "bare" RSA signature = output just the N-size bits not the additional data wrapping such a signature in X.509 or PKCS#7 etc, rather than "raw" RSA = "textbook" RSA = just $x^d mod n$ without hash/ASN.1/padding per PKCS#1. Commented Aug 23, 2014 at 18:59
  • @fdama the receiver (database) getting the public-key from a certificate instead of being fixed as Thomas interpreted, means that instead of using a fixed private-key to sign, you must use a private-key corresponding to a certificate. If whoever issues these certs will issue a new one for a key you create and keep that is ideal, otherwise you need to "share" the cert AND KEY from some existing sender. If the "Company"s are separate businesses they probably won't take the risk of sharing. If the database system owner has an "internal" or "test" cert, they may. Commented Aug 23, 2014 at 19:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .