I have been getting the following warning on my website :
This site makes use of a SHA-1 Certificate; it's recommended you use
certificates with signature algorithms that use hash functions
stronger than SHA-1.
Which leads to Phasing Out Certificates with SHA-1 based Signature Algorithms
It recommends we can use SHA-256, SHA-384, or SHA-512
But the Question is how do I actually change it ?
Thanks.
Related
How can I verify if a firmware (.bin file) is signed or not , if there is a tool or script that can be used as much I understand sigcheck does not work with firmwares, any help on this ?
A bin file is generally just a binary file. There is no such thing as a (single) standard for firmware files. Undoubtedly the file internally has structure but for us it is impossible to tell what it is. Generally a tool only works for a specific protocol.
RSA signatures themselves are the result of modular exponentiation with the public exponent. The result is then converted to a byte array that is almost indistinguishable from random. The size has the size of the modulus, which is the same size as the key size, in bytes. RSA may be used in various formats such as RSA with PKCS#1 v1.5 padding or RSA with PSS padding; the output however looks the same. Other signature types exist, e.g. ECDSA signatures that are completely different from RSA. They have a different (smaller) size and can be both dynamically and statically sized. ECDSA makes a lot of sense if the signature needs to be checked on resource constrained hardware.
Generally the signature is calculated as the very last step, so often the last bytes of the .bin file will be the signature. If you're lucky the signature is performed using a standard, e.g. PGP compliant signatures or CMS compliant signatures. For CMS signatures you may check if the file contains so called ASN.1 structures. These are encoded using something called BER, which can be parsed (e.g. using openssl asn1parse -inform BER).
So it all depends on the protocol. There is no single tool that can check if something is signed or not, the protocols are too different and signatures themselves just look like random data.
We are implementing SCIM Resource Provider for Users, Groups and a couple of custom resources.
SCIM Core Schema RFC 7643 defines User resource so, that only userName and core attributes (id, schemas) are required. Plus it defines optional attributes like name, profileUrl, etc.
Some optional attributes do not make sense in our context (e.g. ims) or are not supported or very expensive to be supported.
From the other hand, other optional attributes like name should be "required" and should be returned "always".
What is the recommended way to express this, so that the clients would know what attributes should be provided?
As much I understand rfc, we should provide the adjusted, tweaked version of core User schema on /Schemas endpoint. Is it correct way?
Would it make our Provider "none SCIM compliant"?
Discussion has been started on scim mailing list. Here is the answer from Phil Hunt, one of rfc authors:
This happens a lot particularly when adapting SCIM protocol on top of applications (e.g. payroll, HCM, CRM, etc). Each app has data they care about that is a sub-set of what is seen in IDM systems. The point of 7643 is really to define standard attribute names, types, syntax, and handling that developers can count on.
IMO, you do not have to implement the schema exactly as published in 7643. It is quite common practice to omit attributes (e.g. such as an app that doesn’t care about ims). Note that renaming standard attributes or changing their formats will produce interop concerns.
Use the extension mechanism to define your own app specific attributes (see section 3.3 of 7643 and 4.3 for the EnterpriseUser example).
You are free to omit unused attributes from your schema. You document what your server actually supports in the /Schemas endpoint.
The full discussion can be found on https://www.ietf.org/mail-archive/web/scim/current/msg02851.html
I understand that RSA keys can be generated using different sha algorithms. Using openssl, I don't seem to have the option of specifying what algorithm the key generator should use. I suspect it's using sha256.
How can I generate RSA keys using different sha algorithms (such as sha512) in either a bash shell or in Ruby? Does the openssl library support generating RSA keys using different algorithms? If not, does anyone know of another library I can use? (In ruby, OpenSSL::PKey::RSA doesn't seem to allow for choosing an algorithm, but the documentation is hard for me to follow soo...?)
Apologies if this question has already been answered, but I haven't been able to find an answer.
Maybe I should also note (in case I am wrong): it is my understanding that choosing a size for the generated RSA key (i.e. RSA 2048) is separate from choosing the hashing algorithm (i.e. sha512).
UPDATE - Some background
I want to sign Java Web Tokens with an RSA key. The JWT library I'm using gives me the impression that RSA keys can be generated using different hashing algorithms (RS256, RS384, RS512). Generating a key using openssl doesn't seem to let me choose what hashing algorithm is used though.
Thanks!!
RSA keys, and "the RSA algorithm" don't have any notion of a hash algorithm.
An RSA key is just two prime numbers and one other number (from the (p, q, e) triplet all the other values can be derived). e is usually chosen as 0x010001 (though other reasonable values exist) and p and q are generated randomly (while almost any CSPRNG is going to have a backing hash algorithm the CSPRNG itself is usually considered a black box that just emits randomness).
Where a hash algorithm comes into play is in RSA Signatures.
For an RSA Signature the original data is hashed under an algorithm and then the hash value, algorithm identifier, and private key are used to produce a signature (for PKCS v1.5 signatures... for PSS there's also a second (effectively fixed) identifier and some more random bytes).
RS256 is the JWA (JSON Web Algorithms) identifier for "RSASSA-PKCS1-v1_5 using SHA(-2)-256".
JWA section 3.3 says
This section defines the use of the RSASSA-PKCS1-v1_5 digital
signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447]
(commonly known as PKCS #1), using SHA-2 [SHS] hash functions.
A key of size 2048 bits or larger MUST be used with these algorithms.
The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as
follows: generate a digital signature of the JWS Signing Input using
RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired
private key. This is the JWS Signature value.
(emphasis mine)
So no requirement is made on the RSA key, other than that the spec was written in 2015 so they mandated a 2015-compatible minimum keysize.
In the Free Pascal libraries there's a hash library that enables use of MD5 and SHA1 hashing algorithms (http://wiki.freepascal.org/hash). But what if I wanted to use a higher one, such as SHA256 or SHA512? Could I achieve this using Free Pascal? Searching the FP Wiki retunrs zero hits for SHA256\SHA512.
In recent versions (say 2 years or so), there is a package "hash" with units "sha1" and "md5" that implement some basic hashes and checksums
If you need more, most people use DCPCrypt as it is easily converted
http://www.cityinthesky.co.uk/opensource/dcpcrypt
At least I see regularly posts on the lists that people are using it
In Google codesearch I found several units that implement it in pascal.
Query: sha256 | sha512 lang:pascal
One of the sources is from Double Commander, which is a norton/total commander clone that's developed with FreePascal and Lazarus, so there you go.
For other hashes I use "Delphi Encryption Compendium (DEC) 5.2". I don't know if it works with FPC, but you should try. There is THash_SHA512 and THash_SHA256.
Download it from: http://www.torry.net/pages.php?id=519#939342
I have a encryption scheme implemented, the constituent components: The symetric cypher and its chaining mode, and the HMAC algorithm are hard-coded into the binary. Additionally, the parameters of the algorithms (HMAC key, symetric-key symetric IVEC) are specified in binary files, one for each parameter.
I would like to specify the choice of algorithms, and modes, and their parameters in a single file. Do I need my own format, or is this possible using existing OpenSSL infrastructure ? If there is infrastructure, could someone please provide some references.
p.s., I know of the config file parsing code, and the PEM/x.509 code in OpenSSL. However anything built from this won't be cohesive.
I would like to specify the choice of algorithms, and modes, and their
parameters in a single file
That type of agility sounds like you will allow the user to make a choice. Don't do it, since they might pick a bad cipher (or cipher combination). Make good choices for them.
The symetric cypher and its chaining mode, and the HMAC algorithm are
hard-coded into the binary.
I would first look into an authenticated encryption mode - EAX, CCM, or GCM. I believe OpenSSL only has CCM at the moment (or is it GCM?). If you can't use an authenticated encrpytion mode, move on to Encrypt-Then-Authenticate (ie, encrypt then authnticate the cipher text with a HMAC or CMAC), which it sounds like you are doing.
Additionally, the parameters of the algorithms (HMAC key, symetric-key
symetric IVEC)
HMAC (and CMAC) are good. Don't use a CBC-MAC since it suffers from weaknesses on variable length messages.
symetric-key [in binary file]
Hmmm...
symmetric IVEC
IVs are considered public parameters. Pick a random IV for the message, and send it along with the cipher text. Make sure to MAC both the cipher text and IV to detect tampering.
Do I need my own format, or is this possible using existing OpenSSL infrastructure
Look at BIOs for I/O. The encoding is up to you. You can write out raw bytes, you could Base{16|32|64} encode it, you can encode and store it in XML, or store it as name/value pairs.