I work with a smart card which is able to generate RSA keys. But when I generate a key pair, the new generated public and private keys can have some of their most significant bits = 0. Is this OK or does it mean less cryptographic strength?
In some representations, the MSB must be zero, otherwise the value well get treated as a negative number. It should have sufficient non-zero bits such that the modulus is of the size you wanted to generate, otherwise, yes it is less secure.
Related
Is it possible to encrypt a plaintext using the secret key in SEAL?
Does the symmetric variant help in increasing the noise budget of the ciphertext, or improve the homomorphic evaluation in some other way?
No symmetric key primitives are implemented in SEAL 3.2. There are some benefits:
Smaller initial noise;
Possibility to replace half of a freshly encrypted ciphertext with a random seed, resulting in ~ 50% reduction in message expansion (but only in fresh ciphertexts). This can be significant.
The only problem with the symmetric key schemes is that the ciphertexts can't easily be re-randomized since without the public key there isn't any easy way to create fresh encryptions of zero. As a result, it might be hard or impossible to create provably secure protocols where the computation depends on the private data coming from other sources than the secret key owner (through multiply_plain and add_plain).
Standard(PKCS#1) says that length of message used to sign must be emBits = modBits — 1. But where is it from? I mean in this standard signature is based on a hash and hash is supplemented to a length emBits. But why is it must be modBits — 1? To create a digital signature of the right size?
Let's pretend you have a modulus value of 0b1010111111 (10 bits).
If you run EMSA-PSS-Encode(M, 10) it could (if capable of producing numbers that small) produce 0b1111001011. That value exceeds the modulus, so it's mathematically equivalent to 0b100001100. When running verify you get the intermediate value of 0b100001100, then find that your signature fails to verify. You sign it again, this time it works. Confusion abounds.
The answer, ultimately, is "to have a stable algorithm which gets as close to the modulus value as possible without exceeding it". Similarly, EMSA-PKCS1-v1_5 starts with a zero-byte, to ensure the modulus is always a larger number than the encoded value.
I know about length of some small encrypted strings as: 160, 196 ..
What determines the size?
The size in bytes of a single "block" encrypted is the same as the key size, which is the same as the size of the modulus. The private exponent is normally about the same size, but may be smaller. The public exponent can be up to to the key size in size, but is normally much smaller to allow for more efficient encryption or verification. Most of the time it is the fourth number of Fermat, 65537.
Note that this is the size in bits of the encrypted data. The plain data must be padded. PKCS#1 v1.5 uses at most the key size - 11 bytes padding for the plain text. It is certainly smart to keep a higher margin though, say 19 bytes padding minimum (a 16 byte random instead of a 8 byte random for padding).
For this reason, and because it is expensive to perform RSA encryption/decryption, RSA is mostly used in combination with a symmetric primitive such as AES - in the case of AES a random AES symmetric secret key is encrypted instead of the plain text. That key is then used to encrypt the plain text.
I am using a AES algorithm in my application for encrypting plain text. I am trying to use a key which is a six digit number. But as per the AES spec, the key should be minimum sixteen bytes in length. I am planning to append leading zeros to my six digit number to make it a 16 byte and then use this as a key.
Would it have any security implications ? I mean will it make my ciphertext more prone to attacks.
Please help.
You should use a key derivation function, in particular PBKDF2 is state-of-the-art in obtaining an AES key from a password or PIN.
In particular, PBKDF2 makes more difficult to perform a key search because it:
randomizes the key, therefore making precomputed password dictionaries useless;
increases the computational cost of testing each candidate password increasing the total time required to find a key.
As an additional remark, I would say that 6 digits correspond roughly to 16 bits of password entropy, which are definitely too few. Increase your password length.
I've been tasked with implementing an XOR hash for a variable length binary string in Perl; the length can range from 18 up to well over 100. In my understanding of it, I XOR the binary string I have with a key. I've read two different applications of this online:
One of the options is if the length of my key is shorter than the string, I divide up the string into blocks that are the length of the key; these are then all folded together (so the length of the resulting hash would be the length of the key).
I've also read that you just XOR the key across each key-length block of the string (so the resulting hash would be the length of string).
Is one of these more correct than the other? This is for hashing values in an index, so I'm inclined to think the first option (which could produce shorted hashes) would be better.
Finally, is there a good way to generate a sufficiently random key? And is there a good length to choose for the key based on the length of the strings to be hashed?
EDIT: By the way, I am very aware of how bad this hash works. It's strictly for comparison purposes. :)
One other alternative, from here (search for XOR hashing).
Assuming the hash is supposed to be x bytes long, break the message into blocks of x bytes; and xor them together. This is effectively the same as using method 1 with a key of x 0's. (or, alternatively, starting with a key of the first x bytes of the string, and ignoring those first bytes of the string. All manner of fun ways to think about it)
(Also note what is said about XOR hashing, namely that it is bad. Very bad.) (Roughly. It's better then alternatives, but it is not sufficient for a lot of what hashing is used for)
EDIT: One other small thing; if method 1 uses the same key across all binary strings that are hashed; then it doesn't really matter what the key is. xor'ing against a constant is akin to, say, ROT13. <sarcasm>Alternatively, if you use SHA1 to derive a key per string... that might make the XOR hash much better.</sarcasm>
key xor key == 0 //always
key xor (((key xor msg1) xor msg2) xor msg3)
== (msg1 xor msg2 xor msg3)
Generally you want your hash values to all be a consistant length. The second method you describe sounds like encryption where you want to recover your data, the first is a one way hash.
xor is not a really good way to hash:
1 is sort of a hash since you realy cant get the original data back, with or without a key. i suggest using sha2 (224/256/384/512), md5, ripemd160 or whirlpool, if you can
2 is an xor cipher with a repeating key. it is definitely not a hash.
as for generating random numbers, you can find programs that generate irrational numbers in hex (like pi: 3.243F6A8885A308D313198A2E03707344A4093822299....)
The first technique can be used to create a quick and dirty hash of the string.
The second technique can be used to create a quick, dirty and terribly insecure symmetric encryption of the string.
If you want a hash, use the first method (or even better, pick an existing hash function off-the-shelf.)
The randomness of the key isn't going to be your biggest issue - the whole technique is insecure.
The longer the key, the more distinct hash values you will get, the less likely you have a collision. It doesn't take long before collisions are very rare for moderately sized data sets.
If you want to perform a 'hash' that only uses XOR, I'd simply split the string up into blocks of some predetermined size X. Don't forget to somehow compensate for when the input string is smaller than X.