I want to make a javascript library for signing messages. I expect the format to be something like...
--- BEGIN SIGNED MESSAGE ---
This is a plain old message
It goes on and on...
--- BEGIN RSA OF SHA1 ---
Base64Stringassfd86asdf870n8
09as8d76fn098==
--- END SIGNED MESSAGE ---
But I don't know the correct format. I could replicate PGP format (I am sure it is not hard to find info on that) but I would prefer to use a standard method if there is one.
Is there a standard format for this kind of signed message?
Cryptographic Message Syntax (a.k.a PKCS #7) is a very commonly used format for signed data. It also supports encryption and authentication of payload contents, so it's a bit of an uber-format. The downside is the complexity of implementation - the specification can be tiresome to trawl through and you have to be comfortable working with ASN.1.
OpenPGP format is likely to be simpler to implement and more readable to the human eye (no ASN.1 to be seen). This might be the best bet for simplicity. Again, you would have the option to add encryption at a later date, if you so desired. However, the specification can be equally infuriating to work with - I've never encountered an RFC that was so... imprecise before.
For sake of completion, W3C XML Signature, it is slightly easier from the syntax and encoding perspective but requires that the final data is in XML.
Related
I am fairly new to cryptography, but I have come across this :
ea706916-4d0a-460d-9778-4d1a7195b229
which looks like a familiar format. It's original value is tjotol.
Would anyone know what format the above code is in? I know that if it has hashes it can be a giveaway. Base64? HTML? Something else?
It does not look like Base64, it may be MD5 with dashes in-between. However, remember that a hash is a one-way function (ie. it's not reversible), while a cryptographic function is two-way (you can encrypt and decrypt it). Hence, it's not correct to speak about "hash decrypting". I don't know what you mean by "format language", would you care to elaborate on that?
A quick google search took me to this article that seems to be well written an covering many issues regarding your concern related to hashes being a "giveaway".
Note: Base64 is hardly an encryption algorithm, it is indeed just an encoding/representation format.
This have the format of a Globally unique identifier (GUID). Take a look here: Globally unique identifier
I am looking for a Stream Cipher encryption method, that will result in the encrypted string being prefferably as short as possible, and containing alphanumeric characters only.
Is there such a thing built in .NET? I have researched but could not find something like this.
Thank you,
I found the answer here Really simple short string compression, meaning its not possible, as encryption means also making the value longer. The best that can be done is keeping the same size of the input, but if the result must be alphanumeric then a longer string is a must
You can make it shorter - just zip the resulting encrypted string using java or some other library and output as hex. Pretty straight forward.
A lot of the examples online show the hash as a hex representation, and they are typically custom implementations. Is there anything wrong with, or less secure about, using the Apache Commons Base64 encoding instead? When reading about encoding, it is usually within the realm of how to represent binary as text in XML, but does not necessarily discuss security concerns... just how the compression works.
On a related issue, why encode it all, since databases have binary types that could probably hold the encryption as binary? So if I'm storing a password, why not just store it in its native type?
An encoding affects only the representation of the data, not its security. So, if you send an unencrypted password and use some form of encoding, you've not made it any more secure; likewise, if you take some highly encrypted text and then represent it in some encoding scheme, that won't make it any less secure, either. Typically, the reason to use this form of encoding is to send binary data using a protocol (such as SMTP), where the protocol is only capable of supporting 7-bit ASCII text. Another use is in URLs, where the set of characters that a URL can support is limited, but you might want to put arbitrarily complicated binary data in that URL (such as a validation signature of some sort).
Not at all. It's just an encoding that represents the same bits in ASCII. It is mostly useful when you have to store or transmit binary data over communications paths designed to handle only text. Modern examples ore email and web interfaces. You also can't send the binary form to a terminal to view it, since it would result in garbage or strange terminal behavior.
If you can safely store the bits in a binary blob in a database there is no reason to encode in base64. But if you don't it would be harder to view it. You would have to convert it back to a text form first.
Well we typically don't do too well reading binary, and hex is a better substitute for that. I wish you had linked to the articles you were referencing, so others could have a direct line on what it is you're forming an opinion from.
I don't understand why they would use Base64 over hex, but I'm assuming it's because hex is 16 digits and Base64 is a few more, thus generating a more compact version of the actual hash ;) ~ We humans tend to do better absorbing a small amount of data at a time.
No, because Base64 is a 1:1 encoding (that is, for every input there is exactly one base64 encoded output, and vice-versa), base64 encoding a SHA1 hash is just as “secure” as a hex-encoded (or binary-encoded, for that matter) hash.
The encoding would only make a hash insecure if the encoding made it possible for multiple hashes to encode to the same string, or multiple strings to decode to the same hash.
Is there any ways to try to guess encryption algorithm used to encrypt the ciphertext?
Yes. There are some differences:
Is it a block cipher or not can be guessed from the length.
Block length
Entropy of the output (are all characters equally present? / can patterns be found?)
Recurrences (CBC or not...)
The entropy of the string is probably the best hint. A simple method to determine it is probably trying to compress it. Some methods can be found here: http://www.random.org/statistics/ They use them to make sure their numbers are as random as possible.
I've got no idea if it's really possible to determine the encryption using these methods.
Tools to see it:
PEiD with the Krypto Analyzer (KANAL) plugin
IDA Pro with the Findcrypt plugin
OllyDbg with the SnD Crypto Scanner
x3chun's Crypto Searcher
Keygener Assistant
Hash & Crypto Detector (HCD)
Draft Crypto Analyzer (DRACA)
but all to executables.
found here : http://fwhacking.blogspot.com.br/2011/03/bfcrypt-crypto-scanner.html
Quite often this information is readily available - in a good encryption scheme, only the key needs to be secret, not the algorithm used.
There are analyses you can can perform to test for particular encryptions, consult a textbook on cryptanalysis for details!
You can try fbcrypt which will scan for known hash & crypto signatures: http://fwhacking.blogspot.com/2011/03/bfcrypt-crypto-scanner.html
For now it supports MD5, CRC32, Blowfish, DES and SHA256, but more will be added soon. Anyway as the source is available you can also add your own.
It depends if you're talking about "raw encrypted data" (in that case you can use methods such as listed by "gs" in the other answer) or an encrypted file in some standard format (the most common are CMS/PKCS#7 and OpenPGP); in the latter case the encryption algorithm is explicitly indicated in the metadata contained in the very file.
For CMS you need an ASN.1 decoder such as command-line dumpasn1 program or my own web-based Javascript decoder while for OpenPGP you can use pgpdump.
I realize this question might not be that programming related, and that it by many will sound like a silly question due to the intuitive logical fault of this idéa.
My question is: is it provable impossible to construct a cryptographic scheme (implementable with a turing-complete programming language) where the encrypted data can be decrypted, without exposing a decryption key to the decrypting party?
Of course, I can see the intuitive logical fault to such a scheme, but as so often with formal logic and math, a formal proof have to be constructed before assuming such a statement. Is such a proof present, or can it easely be constructed?
Thank you for advice on this one!
Edit: Thank you all for valuable input to this discussion!
YES!!! This already exists and are called zero knowledge protocols and zero knowledge proofs.
See http://en.wikipedia.org/wiki/Zero-knowledge_proof
However, you have to have a quite a good background in mathematics and crypto to understand the way it works and why it works.
One example of a zero knowledge protocol is Schnorr's ZK protocol
No; but I'm not sure you're asking what you want to be asking.
Obviously any person who is decrypting something (i.e. using a decryption key) must, obviously, have the key, otherwise they aren't decrypting it.
Are you asking about RSA, which has different keys for decrypting and encrypting? Or are you asking about a system where you may get a different (valid) result, based on the key you use?
If by "decrypted" you just mean arrive at the clear text in some way, then it is certainly possible to create such a cryptographic scheme. In fact it already exists:
Take an asymmetric encryption scheme, eg: RSA where you have the public key but not the private key. Now we get a message that's been encrypted with the public key (and therefore needs the private key to decrypt it). We can get the original message by "brute force" (yes, this'll take an enormously long time given a reasonable key/block size) going through all possible candidates and encrypting them ourselves until we get the same encrypted text. Once we get the same encrypted text we know what the decrypted text would be without ever having discovered the private key.
Yes.
Proof: Encryption can be considered as a black box, so you get an input and an output and you have no idea how the black box transforms the input to get the output.
To reverse engineer the black box, you "simply" need to enumerate all possible Turing machines until one of them does produce the same result as the one you seek.
The same applies when you want to reverse the encryption.
Granted, this will take much more time than the universe will probably live, but it's not impossible that the algorithm will find a match before time runs out.
In practice, the question is how to efficiently find the key that will decode the output. This is a much smaller problem (since you already know the algorithm).
It's called encoding.
But everyone with the encoding algorithm can "decrypt" the message. This is the only way of keyless encryption.