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.
Related
I'm doing an R&D project focused on encrypting information into cipher-text and then printing it as a Code-128 barcode.
It is my understanding that since code-128 barcodes can only retain the ASCII table up to 128 characters. Therefore, I need to know if the cipher-text output of modern algorithms such as AES or RSA can be restricted to only the ASCII-128 table.
I am not doing any programming at this point, I am mainly trying to find precedence that this is can be done or has been done. If anyone knows the answer to this question, and better yet could provide a reference to an example, I would be very grateful.
bonus question... if restricting the ciphertext to ascii-128 is possible, how much could it affect encryption strength?
Encode resulting cipher-text, which is binary, with Base64, which is ASCII. Then you will be able to print base64-encoded cipher-text as
barcode.
Since Base64 encoding decoding doesn't change content, but rather changes its presentation, it doesn't affect underlying cryptography strength.
If resulting data won't fit into 103 (255) characters of Code 128, consider using QR Code instead.
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
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.
Just found this website: hashpass.com and here is the JS implementation which they use to encrypt the key-value pair: http://hashapass.com/sha1.js
So, can there be a "simple" and obvious alternative to this?
Thanks
I'm not sure how secure this is. For one thing, the output is a short Base64 string. Due to its length and restricted character set, it should be easier to brute-force than a regular password that avoids the common and dictionary values while combining alpha, numeric and other.
You want it to be simpler in <what?> way? You want it to be more obvious in <what?> way?
Do you care about the cryptographic strength?
If you don't care about that, you can simply take a sum modulo 2<<32 (or something) and encode the result as 8 hex digits.
I sure wouldn't trust my logon to that kind of security , but is
simple
obvious
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.