It was my belief that the PEM encoding were unique.
But I have seen that the same certificate can have two different pem versions. Or at least, I have two PEM certificates that contain the same information (serial number, CA issuer etc...) so they should be the same.
Can the same certificate have two different PEM encoding?
There are no two different encoding versions for same set of certificate data.
Presentation in PEM may be slightly different. I mean, PEM may include or missing PEM header and footer, Base64-encoded payload may or may not have line breaks after 64 characters, but it doesn't affect the Base64-encoded value, because line breaks are not part of encoding and ignored by Base64 encoder/decoder. The raw value unchanged for single certificate.
Update:
Exact PEM format is defined in RFC 1421, but it is not always followed and I see different presentations which can be called PEM as well (even though they don't strictly follow RFC). For example, I saw such as:
-----BEGIN XYX-----
<Base64 string split in 64 chars per line>
<Base64 string split in 64 chars per line>
<Base64 string split in 64 chars per line>
-----END XYZ-----
or
-----BEGIN XYX-----
<Long Base64 string split in single line (without line breaks>
-----END XYZ-----
or even this:
-----BEGIN XYX-----<Long Base64 string split in single line (without line breaks>-----END XYZ-----
or variations of these formats. Only first example is legit PEM format, while the rest are not-compliant, but can be called PEM, because they have PEM header and footer, and Base64-encoded payload.
In addition to the nonstandard but often accepted (mis)encodings described by Crypt32:
As stated in RFC7468 several different 'types' have been used for X.509 certificates, including plain CERTIFICATE or X509 CERTIFICATE or X.509 CERTIFICATE. These contain the same data, and it's debatable whether this is really a different encoding.
OpenSSL, and some things compatible with it, have a related but distinct PEM type TRUSTED CERTIFICATE where the data actually consists of the X.509 certificate (in DER) plus an added DER blob containing trust information proprietary to OpenSSL. This is different, but only a little.
A certificate, or several, can be packaged in a PKCS7 or CMS 'container', often using the p7b or p7c extension if it's in a file or URL. A PKCS7/CMS containing a cert is a different thing from the cert itself, though it can sometimes be used interchangeably (Microsoft CertMgr, I'm looking at you), and the PEM encoding of a PKCS7/CMS containing a cert is different from that of the cert itself.
Related
I am trying to base64 decode of the following cookie from CTF challenge as a learning exercise
%2BiEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H%2BINemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
This cookie contains a flag that needs to be decrypted. I tried using the following command in Linux but it returns garbage
echo "%2BiEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H%2BINemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX" | base64 -d
I know % is not a base64 character. How can I decode this cookie since it contains % and get the flag that can be further decrypted?
Following Luke Josha Park's suggestion, I did the following in Chrome Developer's console
cookie=atob('+iEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H+INemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
')
and I am getting
"ú!¶SÈ¡L!]l^Mb¥ÎÃÔ5é8´) ù,§.Òó«aCüµwÿ³jÙ»å(©L}HâO:>\Êaº7y1Ayìñ"±3¶¦"
How to make sense of it or have I done it incorrectly?
%2B is the URL encoding of the symbol +, which is a base64 character. Try URL decoding your original string to produce:
+iEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H+INemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
I'm trying to use the HERE route match API, and I'm confused about the file parameter when attempting to use the GET interface. The API for the file parameter states:
Base64 encoded string that contains the (zipped or plain) trace file
content. Zipped can be PKZip (used by zip, WinZip, 7Zip etc) or ZLib
(used by deflate) format. Only used for GET requests. In POST
requests, the file is sent as request body, not Base64 encoded, plain
or zipped. Note: Browsers limit the size of the file to a few KB when
passed in a GET request.
I've chosen to use the GPX format for my waypoints. Questions:
What is the required character encoding of the underlying XML
characters when sending plain or zipped trace file content?
Are there specifications for the compression method (Deflate, Deflate64,
etc.) and compression level?
Are there required specifications for
the type of base64 encoding?
I can definitively answer #3, and that requires URL safe encoding.
I writing an application that using http request for authentication. Because of security matter, I am using WireShark to sniff the http packet to see if can steal the username and password.
When using WireShark, I got this encoded string:
TlRMTVNTUAADAAAAGAAYAHIAAADcANwAigAAAAQABABYAAAAEgASAFwAAAAEAAQAbgAAABAAEABmAQAAFYKI4gYDgCUAAAAP255D/F478qJlQoJwEti1LGgAcABzAGwAZQBlAGsAYgBvAG8AawBIAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGao0slMmaggkTP6jJJHJUwEBAAAAAAAABaWp/E9p0QGDaAQ319vuYgAAAAACAAQASABQAAEABABIAFAABAAEAGgAcAADAAQAaABwAAcACAAFpan8T2nRAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAAkOEBAmC7E+a9Pa8Y4gF0J9zeqVTsT7BCXKEhznVGMpwoAEAAAAAAAAAAAAAAAAAAAAAAACQAkAEgAVABUAFAALwAxADkAMgAuADEANgA4AC4AMQAuADEAMQAzAAAAAAAAAAAAAAAAAFq8ggyPeAnfXnSiV12/Z1Y=
I do research online, and I guess this is Base64 encoded. Then, I tried to decode from this website:
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
I managed to see my username which is sleekbook, but the others still seems unknown to me. Is it because it's not Base64 encoding or it's further encrypted by some other algo as well?
I'm sending some pre-encrypted strings (AES) to a REST API, this is data that has been encrypted by the client. I am storing the data, and never decrypting it on the server side.
I will hand it back to the client later.
My initial thought was to use base64 encoding to ensure the data survives the form post. Is this the correct way to do things?
You do not need any special encoding to POST data to a server, as there is no restriction to what characters you can use.
If you choose to send the encrypted data as binary data, you should specify content-type header to be application/octet-stream.
What are the differences between .pem, .cer and .der?
As far as I know, .cer contains public key. Are there any open frameworks that I can use to encrypt my data using this public key?
.pem, .cer and .der are all file extensions for files that may contain a X.509 v3 certificate.
The .der extension
DER is the method of encoding the data that makes up the certificate. DER itself could represent any kind of data, but usually it describes an encoded certificate or a CMS container. CMS is described in PKCS#7 (often stored as .p7) and stands for Cryptographic Message Syntax, which can be used to protect messages and to store certificates to allow a receiver to build a trust path to a certificate in the receivers' trust store.
The structure of a certificate is described using the ASN.1 data representation language. BER and DER are binary encoding methods for data described by ASN.1.
The .pem extension
PEM is a method of encoding binary data as a string (also known as ASCII armor). It contains a header and a footer line (specifying the type of data that is encoded and showing begin/end if the data is chained together) and the data in the middle is the base 64 data. In the case that it encodes a certificate it would simply contain the base 64 encoding of the DER certificate. PEM stands for Privacy Enhanced Mail; mail cannot contain un-encoded binary values such as DER directly.
PEM may also encode / protect other kinds of data that is related to certificates such as public / private keys, certificate requests, etc. If the contents are a common X509v3 certificate then the PEM is encoded as:
-----BEGIN CERTIFICATE-----
... base 64 encoding of the DER encoded certificate
with line endings and padding with equals signs ...
-----END CERTIFICATE-----
Note that a PEM file may also contain a complete certificate chain, where the chain starts with the leaf / end certificate of the service, followed by the certificate that signed it, usually up to but not including the trusted root certificate. So if you're missing certificates you may want to take a look behind the first one.
The .cer or .crt extension
.cer just stands for certificate. It is normally DER encoded data, but Windows may also accept PEM encoded data. You need to take a look at the content (e.g. using the file utility on posix systems) to see what is within the file to be 100% sure.
Other OpenSSL formats
Take a look at this answer for a more extensive list of what is supported by OpenSSL.
To use the public key contained in the certificate (and signed by the signature in the certificate) you should use any library that parses X.509 certificates and performs RSA encryption. You could use a tool that detects/handles PEM encoding or you could first convert the certificate to DER by stripping off the PEM encoding.
The OpenSSL command line contains lots of options to convert between PEM and DER, print out high level certificate information or parse the ASN.1 to get a low level view of what is in there.
Details
Like most ASN.1 structures, DER encoded certificate always starts off with a byte 30 which is the tag encoding of an ASN.1 SEQUENCE. If you're seeing a lot of repetition in the file then this is OK; it is just the structure that is strictly defined.
Likewise, the base 64 within a PEM encoded file always starts off with the letter M as an ASN.1 SEQUENCE starts off with a byte 30, so the first 6 bits are 001100, which translates to the number 12, which is the index of the letter M, the thirteenth letter of the alphabet.