Sample X509 Certificates with Wrong ASN.1 Encode - x509certificate

For testing purpose, I am looking for sample X509 Certificates with wrong ASN.1 encoding, like Null with length more then Zero, etc. Any pointers??

Take any certificate and save it to file.
Download Asn.1 editor and open the certificate in it. Now doubleclik any asn.1 element and edit it (i.e. change value of an oid. it will at least invalidate the signature). If you want to break asn.1 encoding then then view it in hex to find what byte to edit.
When you select NULL asn.1 element it will show you in hex viewer what bytes it is encoded in. Green color represents Length octet. Change it in any hex editor.

Related

Which encryption / encoding that starts with 'FU' ends with '=='? Or start with '\x' (backslash x) [duplicate]

I have a plain text and its encoded string, I wanted to know which encoder/algorithm is used to encode the string.
Plain Text: hello world
Encoded Text: 3MZ7hIAnvqtIqnxZJyEi+dOuJ1/myCfsbYOCsYKkZto=
I know it has something to do with base64, but I have tried it not working for me.
Edit:
I have a notepad like exe, in which I wrote "hello world" then saved it. When I open the text file in a normal notepad it shows me "3MZ7hIAnvqtIqnxZJyEi+dOuJ1/myCfsbYOCsYKkZto=". And When I open the same file in the exe (where I wrote), it shows plain text "hello world".
There are two common misunderstandings/misconceptions regarding base64 encoded strings:
The expectation to get readable text after decoding a base64 encoded string, along with the assumption that either the encoding is different or the base64 decoder doesn't work when the result doesn't meet the expectation
The given string seems to be base64 encoded, it only contains characters from the base64 character set and it is correctly padded, so it's very likely a base64 encoded string. Base64 encoding is used to encode all kinds of data, but a very common use case is to encode binary data (that would not be printable or only shown as a string of 'weird`' symbols) into an easier to handle form. One typical use case is to base64 encode the result of encryption or hashing, which both create binary results.
The expectation that base64 decoding is the only step necessary to get back the original (e.g. plain text, password, etc.)As mentioned above, base64 is often used to encode the binary result of encryption or hashing. Base64 alone is not encryption and (hopefully) never used to secure passwords or other confidential information.
"hello world" in base64 encoding is "aGVsbG8gd29ybGQ=", and everyone can decode it with any base64 decoder. The process for passwords is usually to first hash the password and then base64 encode the binary hash value. For other confidential information it's encrypting and then base64 encoding.
Having said this, the conclusion is that the given string is likely a base64 encoded hash or encrypted text.
The typical follow up question is: If this binary gibberish that I get from decoding is the result of encryption or hashing, how do I get the plain text?
The answer for this is: probably not at all, at least not based on the given information.
If it's a hash, there is nothing to decrypt as hashing is a one-way process.
If it's encrypted, there is no information how to decrypt this. For decryption you would need to know the encryption algorithm and the key.
And in case of hashing or encryption, the binary information usually doesn't contain any marker that marks the data as being the result of any certain hashing or encryption algorithm.
The only information I can get from the base64 encoded string (aside from the binary result) is the length. The given string is 44 characters long including one padding character, that's 43 * 6 (every base64 character encodes 6 bits) = 258 bits, so probably 256 bits. That could be, for example, a sha-256 hash, but really just a possibility.
The later added paragraph in the question about the program that stores the base64 string and retrieves the original data after reading it
makes it likely that the base64 string contains encrypted information, but that's all I can get from it.

I am unable to identify this hash-type ? is it a base64 hash

I have been given task to penetrate in our high school LAB and having some issues in identifying a hash type as i am aware of some of the major hashes but cant verify if it is a base64 hash because i just cant decrypt it
Hash : 0/922uvfZMC0ZPHMe8Xv2KvsT/E=
Hash : dQWVTNLKCjob+lNr3shxrQqAhYE=
The assigned website contains SQL injection bug running ASP .net server
Please help me in identifying the HASH type
There's no such thing as a "base64 hash". Base64 is an encoding method. What you're looking at is probably a base64-encoded binary hash value.
If you run that base64 string through a base64 decoder, you'll end up with a binary value that is 20 bytes long.
There's no telling how that binary value was created. That is, given a binary value, there's no way to look at it and say, "this was created by the fooby hashing algorithm."

How to detect wrong key used to decrypt openssl rc2-64-cbc nopad

I have some encrypted data, which is encrypted using rc2-64-cbc NO PADDING. I am able to decrypt fine.
The issue : Even if the encrypted content is encrypted with wrong key my decryption doesn't error out, instead it decrypts to some garbage value, as its rc2 and no padding I believe.
I tried from openssl Linux command prompt and my C/C++ program(using EVP_* API calls).
Is there any openssl option/way to detect this the wrong key used ? ( command line or EVP_* C/C++ API calls)
Unless some form of authentication was added to the encrypted data there is no way to know for certain. The best is to look for decrypted that "makes sense", the decrypted data will either be correct or appear as a sequence of bytes that can not be distinguished from random bytes.
Assuming no authentication was added to the message possible methods include:
There is some know correct bytes at a known location in the message, this is known as a crib, an example is in WWII German weather reports began with predictable text.
Make a test of the randomness.
If the data is text check for invalid characters such as 0x00 - 0x1f.
Think of other tests that apply to your data.
You can take the plain text, calculate the checksum and then encrypt both. Once you decrypt the cipher text (even with a wrong key), try calculating the checksum again for the deciphered text and I am sure it will fail.

openssl ccm encrypt a string, how to save tag?

i need to write an encrypted text to a file and then subsequently read the file and decrypt the text. i wanted to use authenticated encryption with openssl evp with ccm, but ccm produces a tag which later must be used to decrypt the text.
the question is - how to store this tag and reuse it across file reads in an isolated pc env (no internet)?
i'm new to encryption, but already appending the tag to the encrypted text before writing to the file and then ignoring the tag bytes when decrypting, kinda smells of bad approach. any hints how to solve this? i cannot ask the user to provide a password before writing/reading the text. the environment is not highly security-sensitive
The tag, frankly, is the point of CCM (or GCM). You can
Delay writing to a file until it's calculated, prepend the tag and nonce (on decrypt, read tag, read nonce, decrypt rest).
Write the nonce, then the ciphertext, then the tag. Recover appropriately
Write the nonce and/or tag to a separate file.
Any of the above, but with more structure than concatenation (e.g. a DER SEQUENCE)
If you're using CCM or GCM you MUST use a different nonce every time you use the same key. Failure to do so can lead to key compromise. (And there's no "well, I know that, but it doesn't matter in this case..." because today's intentionally sloppy code is tomorrow's multi-million dollar bug once it gets copied (as a reference example) to another location).
It is quite common to have nonce, ciphertext, and tag (and "additional data") transmitted in the same message, such as in TLS and IPSEC.

Find the encryption type with the orignal message and the crypted message

Does its possible or does is a tool that can find the encryption method when we have the original message and the crypted message ?
Example : crypted message : ZHVoYW1lbA
: original message : duhamel
example2 : crypted message : ZmV5
: original message : fey
No.
About all you can do is use the length of messages to work out whether it is a block or stream cipher (if it is a block cipher they will be multiples of some fixed size). Even that requires some care as you need to guess whether IV and HMAC or similar have been used (for example, in CTR mode, the (so-called) IV is half a block).
If your examples are real, then that's not a block cipher, because the encrypted messages are too short. And I don't really understand what the encoding is - normally an encrypted message is binary, rather than characters, so is written as a hex string or similar. But your examples seem to be character strings.
So your examples are either made up or something unusual - more likely a "home-made" code than a standard algorithm used in software libraries.
[Edit:] I'm updating this answer after working on https://stackoverflow.com/questions/18560948/encrypted-string-by-unknown-method#comment27312634_18560948
The above is talking about encryption. Sometimes, however, what people are actually asking about is the encoding. That is how the bytes in the (probably encrypted, but perhaps not) message are converted into something that is displayed or sent over the internet, or whatever. This might be hex, or base 64, or something more complex like PEM. Often you can guess this, because different encodings tend to look different. Base 64 often ends with "=", for example. And sometimes, this can give you a clue about the encryption used. For example, PEM has distinctive header lines, which makes it easy to identify, and the default cipher for PEM in OpenSSL is triple DES, so if a file is PEM encoded, it's quite likely it's triple DES encrypted.
So given that, I should have included, in my original answer, the comment that encoding can also help guess the cipher type at times. And in your examples, it's odd that both encrypted strings start with "Z". But I don't know of an encoding that does that.
[see also related comments at https://stackoverflow.com/a/20217208/181772]

Resources