I have a question. For example I have text: "The quick brown fox jumps over the dog!"
It has 32 letters. If I encrypt the first 16 letters with
key: "11111111111111111111111111111111"
and
nonce: "1111111111111111"
and next 16 letters with the same key and nonce will it be secure?
Related
I'm curious about some basics of MD5 encryption I couldn't get from Google, Java questions here nor a dense law paper:
1-How to measure, in bytes, an MD5 hash string? And does it depends if the string is UNICODE or ANSI?
2-Is MD5 an assymetric algorythm?
Example: If my app talks (http) to a REST webservice using a key (MD5_128 hash string, ANSI made of 9 chars) to unencrypt received data, does that account for 9x8=72 bytes in an assymetric algorithm?
I'm using Windevs 25 in Windows, using functions like Encrypt and HashString, but I lack knowledge about encryption.
Edit: Not asnwered yet, but it seems like I need to know more about charsets before jumping to hashes and encryption. https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
An MD5 hash is 128 bits, 16 bytes. The result is binary, not text, so it is neither "ANSI" nor "Unicode". Like all hashes, it is asymmetric, which should be obvious from the fact that you can hash inputs which are longer than 128 bits. Since it is asymmetric, you cannot "unencrypt" (decrypt) it. This is by design and intentional.
On my NetBSD system, there is a password hash in master.passwd that looks like this:
$sha1$[5 numbers]$[8 letters]$[17 alpha numeric].[10 alpha numeric]
For privacy concerns I left out the actual values. Would someone be willing to explain the different parts of this? I was under the impression that SHA1 resulted in 20 bytes, so I was very confused about what part was the actual hash, and what part was the salt, and what part everything else was.
The relevant parts can be found in NetBSD src/lib/libcrypt.
For the format: crypt-sha1.c
The format of the encrypted password is:
$<tag>$<iterations>$<salt>$<digest>
where:
<tag> is "sha1"
<iterations> is an unsigned int identifying how many rounds
have been applied to <digest>. The number
should vary slightly for each password to make
it harder to generate a dictionary of
pre-computed hashes. See crypt_sha1_iterations.
<salt> up to 64 bytes of random data, 8 bytes is
currently considered more than enough.
<digest> the hashed password.
The digest is 160 bits = 20 bytes, but it is encoded using base64 (4 bytes for 3 source bytes) to 28 bytes (with one zero padding byte). See util.c for that.
if there is a password longer then 14 characters, how would LM hash the characters after the 14th and how would it combine it with the hashing from the first 14 characters?
Thank you in advance
Note: LM hash is compromised and should not be used anymore.
LM hash does not support strings longer than 14 characters. If you are going to use the algorithm internally only and do not need compatibility with other systems, you could for example compute separate hashes for each 14 byte block and xor them together.
I want to use AES encryption in my application. I have come across some open source implementations of aes algorithm. By looking at them, I am confused about the following parameters:
AES key length. It is mentioned that key length should be 128, 192 or 256 bytes. What if my key is simply five digits i.e. 23467
AES plain-text length : is there any restriction on the aes plain-text length ?
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
Can anyone help me?
AES key length. It is mentioned that key length should be 128, 192 or 256 bits. What if my key is simply five digits i.e. 23467
It seems you're thinking of the key as a password of sorts. It isn't. A cryptographic key isn't meant to be memorized. It is a long string of randomly generated bytes that should be stored somewhere safe.
You can derivate a cryptographic key from a password, though, for instance using a hash function. In that case you input 234567 and use the resulting digest as the key. This has some security implications, however, as it makes your key vulnerable to dictionary and rainbow table attacks. Look up "password based encryption" for details on how to approach this securely; in particular, have a look at PBKDF2, described in RFC2898.
AES plain-text length : is there any restriction on the aes plain-text length ?
AES is the block cipher, the underlying building block of an encryption system. By itself it can only encrypt a single block of data (16 bytes), so cryptographers have created several "modes of operation" that enable us to encrypt a plaintext of arbitrary length. CTR is a fine example of a mode of operation that does not require any padding and can be parallelized.
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
That's entirely dependent on the mode of operation. In your case it will probably be either 10 (when no padding is required, for example with CTR) or 16 (for block-based modes such as CBC).
I think you mean 128 and 256. (Not 198.)
That's not a key. That's a password. You use an algorithm like PBKDF1 (google it) to derive a key from a password.
No. AES is a block cipher. It works on input blocks that are the same size as the key. You can use as many blocks as you like, chopping up your input into (say) 128-bit blocks. Make sure you use CBC or a similar mode for AES.
Your key is 128 or 256 bits. Your input would be 80 bits (10*8), padded to 128 or 256. Your output length is the same as the key size.
Try to find a crypto library that does most of the work for you. You don't want to mess around with just a basic AES function. You also need to handle IVs, AES modes, possibly a MAC, etc. I can't recommend anything because you don't say what language you're trying to use.
Which symmetrical encryption algorithm to use to encrypt e-mail address(short message)? I would like to have ciphertext to be comparable in length to paintext.
According to Little known features: Symmetric encryption with PGP/GPG:
A little known feature of both PGP and
GPG is that they can also do symmetric
encryption. Just a passphrase is
needed- no public or private keys are
involved. It’s a quick and dirty way
to get strong encryption that even a
novice can use.
To encrypt a file with symmetric
encryption, the syntax is:
pgp --symmetric filename
gpg --symmetric filename
The result is a binary file with the
same name as the original and ".pgp"
or ".gpg" appended.
If the encrypted file must be pasted
into the body of an e-mail message
(instead of added as an attachment),
you’ll want to use the plain ASCII
form of output:
pgp --symmetric --armor filename
gpg --symmetric --armor filename
The result is a plain text file ending
in ".asc"
Decryption is performed using the
usual "-d" switch:
pgp -d filename
gpg -d filename
But I'm not sure this is what you're looking for. Maybe you can clarify your question.
If you really want to have the cipher text comparable in length to the email address, you can use a block cipher in a mode like CFB or OFB that allows encryption of one byte at a time.
However, I don't recommend it, because that gives an attacker a little information about what the message is (how long is the message?). Using an algorithm like 3DES or AES with 16-byte blocks in CBC mode with PKCS #5 padding, most email addresses will be encrypted in two blocks.
I see there is a bit of confusion about lengths of plaintext/ciphertext. Actually, those lengths are quite similar if you use a symmetric encryption algorithm.
Consider a block cipher (e.g. AES). It encrypts 128-bit blocks into 128-bit blocks. So if your plaintext is exactly 128 bits (or its multiple), AES in any mode of operation will produce the ciphertext with the same length. If your plaintext length is not a multiple of 128 bits, then it will get padded to the full block and the ciphertext will be slightly longer (by at most 127 bits). You still can avoid that by using some tricks like ciphertext stealing.
If you use a stream cipher, the encryption process is just XOR-ing bits (or bytes) of the plaintext with bits (or bytes) of the keystream and then the length of the ciphertext is by definition equal to the length of the plaintext.
To answer directly your question, if you don't need any specific format of the encrypted email, just use AES.
If you want the encrypted email to be also in the format of an email, you may want to check how Format-Preserving Encryption works.
#Bobby: ROT13 is NOT an encryption algorithm.
Symmetric block ciphers produce the same length as the input, in multiples of block size (usually 8 bytes or 16 bytes for AES). Because the output is always multiple of block sizes (in fact the output is always the same size as the input and the input must be multiple of block sizes) then you cannot know the original size of the plain text. Common encryption schemes solve this by adding a padding scheme, like PKCS, ISO 10126 or ANSI X923. These schemes place information about the original clear text length in the last block.
If the clear text size is multiple of 8 (16 for AES) then one more block is added to the encrypted text. If the original size is not multiple of block size, then the encrypted size will be rounded up to the next multiple block size.
To this you should add a salt value for each record. A salt (or initialization vector, to be correct) has the same size as a block. Usually is stored in front of the encrypted block.
And finaly you should sign the encrypted value for validation, so you should add a SHA digest, another 20 bytes, otherwise you cannot know for sure if the decrypted value is correct.
So the overall size is (considering AES): 16 bytes (salt) + (clear text size + 20(hash) ) + (16 - (clear text size + 20)%16).
So for john.doe#anydomain.com (lenght 22) the encrypted size will be 16+22+20+(16-10)=64. To decrypt you take the first 16 bytes as salt, decrypt the remaininf 48, the output is lenght 42, you digest SHA the 42-20 = 22 bytes and compare the digets with the last 20 bytes of the decrypted text for validation.
I know is maybe more than you bargained for, but every step in this scheme has a justification.
I would suggest looking into PGP.
To have cypher results comparable with plain text is not a good idea, having differents lenghts is a part of what encryption is about.
I will suggest you one of the most secure encryption algorithms today: AES
But forget about having comparable sizes!
ROT13 or a substitution cypher might work (keys can be changed or exchanged). Encryption with keeping the original text length is...not really that good.
Bobby