I would like to know which drawbacks are there if the public exponent (e) is not coprime with the Euler phi (phi(N)) in RSA. That is to say GCD(e, phi(n)) != 1.
As far as I know the drawback is that in this way we are not sure that there exists a d such that e*d = 1 mod phi. Are there any other drawbacks?
A modular multiplicative inverse of a mod n exists if and only if gcd(a, n)= 1. So, yes, they must be coprime.
Generally, just use 65537 as your public key exponent. There are no advantages for choosing a random e, and 65537 is sufficient large to protect against Coppersmith's Attack and has some qualities that make it particularly efficient for square and multiply algorithms to work with.
Let us take a example: N=65 and e=3.
Then, if we encrypt the plaintext 2, we get 2^3 mod 65 = 8
However, if we encrypt the plaintext 57, we get 57^3 mod 65 = 8
Hence, if we get the ciphertext 8, we have no way of determining whether that corresponds to the plaintext 2 or 57 (or 32, for that matter); all three plaintexts would convert into that one ciphertext value.
Making sure e and ϕ(N) are relatively prime ensures this doesn't happen.
Related
Could the output of the HMAC be the same if I used different keys and messages?
Example:
Out1 = HMAC(key1, msg1)
Out2 = HMAC(key2, msg2)
Could Out1=Out2 under any condition?
In short, you can't find such pairs better than negligible probability when the search is computationally bounded.
HMAC is a Pseudo-Random Function (PRF) under the assumption that the used hash function is PRF.
What you are looking for a collision for the HMAC. In theory, it is possible to find such pairs that they will collide.
If you use a n bit output then the collision probability of two pairs is 1/2^n for the fixed key. If HMAC is initiated with SHA256 then the collision of two random pairs will be 1/2^256. By the birthday paradox, you will need around 2^128 pairs to find a collision with 50% under the same key.
A similar calculation can be performed with random keys, too.
The answer is actually yes! >ou can create such collisions, and they are very easy to find. For a proof, see this python snippet:
import hmac
m1 = b"PAYLOAD"
m2 = m1
key1 = b"PADDING\x00"
key2 = b"PADDING"
out1 = hmac.new(key1, m1, "sha256").digest()
out2 = hmac.new(key2, m2, "sha256").digest()
print(key1 == key2) # Different keys
print(out1 == out2) # same digest
The example above shows different key-message pairs producing the same output.
The reason for this is in the design of HMAC itself, and keys of different lengths are processed. See Step 1 of HMAC description in section 2.
Is this an issue? In practice? No, since in the proper usage of HMAC as a MAC or a PRF, the key is randomly chosen and has usually a fixed size. An attacker doesn't have the same luxury as we had in the code above. In theory? It could be in a case where you are trying to formally prove your protocol and rely on the fact that these collisions are hard to find even if the attacker controls both the key and the input.
I have a hardware-based boolean generator that generates either 1 or 0 uniformly. How to use it to make a uniform 8-bit integer generator? I'm currently using the collected booleans to create the binary string for the 8-bit integer. The generated integers aren't uniformly distributed. It follows the distribution explained on this page. Integers with ̶a̶ ̶l̶o̶t̶ ̶o̶f̶ ̶a̶l̶t̶e̶r̶n̶a̶t̶I̶n̶g̶ ̶b̶I̶t̶s̶ the same number of 1's and 0's such as 85 (01010101) and -86 (10101010) have the highest chance to be generated and integers with a lot of repeating bits such as 0 (00000000) and -1 (11111111) have the lowest chance.
Here's the page that I've annotated with probabilities for each possible 4-bit integer. We can see that they're not uniform. 3, 5, 6, -7, -6, and -4 that have the same number of 1's and 0's have ⁶/₁₆ probability while 0 and -1 that all of their bits are the same only have ¹/₁₆ probability.
.
And here's my implementation on Kotlin
Based on your edit, there appears to be a misunderstanding here. By "uniform 4-bit integers", you seem to have the following in mind:
Start at 0.
Generate a random bit. If it's 1, add 1, and otherwise subtract 1.
Repeat step 2 three more times.
Output the resulting number.
Although the random bit generator may generate bits where each outcome is as likely as the other to be randomly generated, and each 4-bit chunk may be just as likely as any other to be randomly generated, the number of bits in each chunk is not uniformly distributed.
What range of integers do you want? Say you're generating 4-bit integers. Do you want a range of [-4, 4], as in the 4-bit random walk in your question, or do you want a range of [-8, 7], which is what you get when you treat a 4-bit chunk of bits as a two's complement integer?
If the former, the random walk won't generate a uniform distribution, and you will need to tackle the problem in a different way.
In this case, to generate a uniform random number in the range [-4, 4], do the following:
Take 4 bits of the random bit generator and treat them as an integer in [0, 15);
If the integer is greater than 8, go to step 1.
Subtract 4 from the integer and output it.
This algorithm uses rejection sampling, but is variable-time (thus is not appropriate whenever timing differences can be exploited in a security attack). Numbers in other ranges are similarly generated, but the details are too involved to describe in this answer. See my article on random number generation methods for details.
Based on the code you've shown me, your approach to building up bytes, ints, and longs is highly error-prone. For example, a better way to build up an 8-bit byte to achieve what you want is as follows (keeping in mind that I am not very familiar with Kotlin, so the syntax may be wrong):
val i = 0
val b = 0
for (i = 0; i < 8; i++) {
b = b << 1; // Shift old bits
if (bitStringBuilder[i] == '1') {
b = b | 1; // Set new bit
} else {
b = b | 0; // Don't set new bit
}
}
value = (b as byte) as T
Also, if MediatorLiveData is not thread safe, then neither is your approach to gathering bits using a StringBuilder (especially because StringBuilder is not thread safe).
The approach you suggest, combining eight bits of the boolean generator to make one uniform integer, will work in theory. However, in practice there are several issues:
You don't mention what kind of hardware it is. In most cases, the hardware won't be likely to generate uniformly random Boolean bits unless the hardware is a so-called true random number generator designed for this purpose. For example, the hardware might generate uniformly distributed bits but have periodic behavior.
Entropy means how hard it is to predict the values a generator produces, compared to ideal random values. For example, a 64-bit data block with 32 bits of entropy is as hard to predict as an ideal random 32-bit data block. Characterizing a hardware device's entropy (or ability to produce unpredictable values) is far from trivial. Among other things, this involves entropy tests that have to be done across the full range of operating conditions suitable for the hardware (e.g., temperature, voltage).
Most hardware cannot produce uniform random values, so usually an additional step, called randomness extraction, entropy extraction, unbiasing, whitening, or deskewing, is done to transform the values the hardware generates into uniformly distributed random numbers. However, it works best if the hardware's entropy is characterized first (see previous point).
Finally, you still have to test whether the whole process delivers numbers that are "adequately random" for your purposes. There are several statistical tests that attempt to do so, such as NIST's Statistical Test Suite or TestU01.
For more information, see "Nondeterministic Sources and Seed Generation".
After your edits to this page, it seems you're going about the problem the wrong way. To produce a uniform random number, you don't add uniformly distributed random bits (e.g., bit() + bit() + bit()), but concatenate them (e.g., (bit() << 2) | (bit() << 1) | bit()). However, again, this will work in theory, but not in practice, for the reasons I mention above.
I'm using python and cryptography.io to sign and verify messages. I can get a DER-encoded bytes representation of a signature with:
cryptography_priv_key.sign(message, hash_function)
...per this document: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/
A DER-encoded ECDSA Signature from a 256-bit curve is, at most, 72 bytes; see: ECDSA signature length
However, depending on the values of r and s, it can also be 70 or 71 bytes. Indeed, if I examine length of the output of this function, it varies from 70-72. Do I have that right so far?
I can decode the signature to ints r and s. These are both apparently 32 bytes, but it's not clear to me whether that will always be so.
Is it safe to cast these two ints to bytes and send them over the wire, with the intention of encoding them again on the other side?
The simple answer is, yes, they will always be 32 bytes.
The more complete answer is that it depends on the curve. For example, a 256-bit curve has an order of 256-bits. Similarly, a 128-bit curve only has an order of 128-bits.
You can divide this number by eight to find the size of r and s.
It gets more complicated when curves aren't divisible by eight, like secp521r1 where the order is a 521-bit number.
In this case, we round up. 521 / 8 is 65.125, thus it requires that we free 66 bytes of memory to fit this number.
It is safe to send them over the wire and encode them again as long as you keep track of which is r and s.
So im generating 2048 RSA keypair. But when i look at the private key the lenght is only 1232 bytes. Does this have anything to do with the 2048 or is the 2048 just the modulus size?
The size of a RSA key is expressed in bits, not bytes. 2048 bits are 256 bytes.
A bare-bone RSA private key consists in two integers, the modulus (a big composite integer, its length in bits is the "RSA key length") and the private exponent (another big integer, which normally has the same size than the modulus). However, the modulus and the private exponent have a bit of internal structure, and knowing details about that structure allows for faster implementations (by a factor of about 4). Hence, RSA private keys usually include some more data.
Namely, if the modulus is n and is the product of two prime numbers p and q, then the private key includes:
the modulus n (256 bytes for a 2048-bit key)
the public exponent e (small, often 65537, i.e. can be encoded over 3 or 4 bytes)
the private exponent d (about 256 bytes)
the factors p and q (128 bytes each)
d reduced modulo p-1 (128 bytes)
d reduced modulo q-1 (128 bytes)
1/q mod p (the inverse of q modulo p; 128 bytes)
for a grand total of about 1160 bytes. Then there is a bit of overhead for the encoding, because all those integers could have lengths slightly different (for instance, nothing really requires that p and q have the exact same size; also, e could be greater than that). The standard structure uses ASN.1, which implies a few extra bytes here and there. It is also common to wrap the structure into a bigger structure which also identifies the key as being a key for RSA. 1232 bytes is compatible with a 2048-bit RSA key encoded in PKCS#8 format.
For details on RSA, have a look at PKCS#1.
Don't forget that 2048 is the length of the modulus in bits, but your measurement of the private key is in bytes. The private key is the modulus and the multiplicative inverse of the public exponent, and depending upon the toolkit you're using, it might also store your CN, DN, (for x509 keys) or subkeys (for GPG keys), so just comparing sizes may not be useful.
Other than the required values (of which the modulus is one, as #sarnold points out) and the fact that you are quite literally comparing bits and bytes, some implementations also compute a few other values up front and store them along with the key, as an optimization. For example, I am not certain but I believe I read that some implementations store the product (p-1)(q-1) (recall that the modulus n is actually the product pq, where p and q are prime).
#Thomas Pornin,
I use both ssh-keygen and openssl genpkey to generate a keypair, each with 2048 keysize, and then print the content, it is like this:
Private-Key: (2048 bit)
modulus:
00:bd:92:7f:da:4f:8f:b0:33:23:0f:d7:f4:12:39:
5d:4d:32:48:1b:6e:de:2d:a5:b9:83:7f:d2:f2:dc:
39:c5:f3:6f:6a:5f:8a:9d:21:9c:01:51:a7:22:99:
70:0d:03:2e:12:63:f2:44:5f:a7:6e:cc:df:44:d9:
8b:b2:7e:fd:8c:c3:ae:62:3e:1e:7e:7a:89:1d:94:
de:86:24:36:d6:f8:23:32:aa:4d:dc:c7:44:87:9d:
68:a5:31:f4:ff:a3:ff:9d:01:57:c9:82:9b:9b:e1:
1c:0f:45:2b:0f:f2:ce:95:4c:13:fb:e9:99:19:82:
64:97:18:77:13:bb:a9:8c:1f:a1:02:cf:92:1a:4d:
13:16:55:8d:06:a8:32:8b:43:80:12:a4:98:77:a7:
cb:7b:4f:e7:be:4e:eb:7b:52:1f:04:49:c9:03:5a:
5b:70:f8:db:c7:8c:99:62:32:cd:3f:fc:70:7f:5e:
de:e9:52:04:f6:19:df:c7:21:bd:28:d8:31:e1:43:
27:ff:ce:43:3a:83:9e:97:69:93:35:46:1f:7f:1d:
4a:43:7f:7f:be:fd:62:c6:f8:a3:9e:07:df:75:4b:
08:4a:47:59:e6:b3:e2:d8:40:29:d4:de:88:54:f5:
6b:e6:e8:77:d5:71:73:c0:1c:0e:8a:b1:ad:25:82:
79:05
publicExponent: 65537 (0x10001)
privateExponent:
42:98:a7:9f:9a:d9:a0:8d:a6:60:97:7d:df:b5:15:
48:dc:44:26:97:01:28:4a:12:ec:d6:47:d6:17:75:
98:4b:d7:b5:27:d1:3b:38:26:64:f4:39:61:d7:43:
5c:de:e4:1d:83:cd:05:26:11:5c:c4:4e:1f:12:c9:
97:b0:33:04:73:6d:dc:87:74:10:fc:9d:14:ae:4a:
aa:17:28:c8:c6:2d:1f:4c:62:c4:0f:a0:cc:7f:88:
d6:97:c1:38:d9:75:1f:c3:ec:02:17:86:f0:f0:d8:
f9:a8:53:e3:6b:6a:15:5a:bf:9e:7c:c6:d3:06:52:
ae:1d:e3:1f:24:8b:00:75:33:ee:aa:b0:69:52:a4:
07:41:60:35:34:67:10:ac:40:b3:5b:70:d7:a7:9c:
c5:aa:08:2e:f5:7b:64:4f:8d:ff:ca:f9:2e:5e:4c:
a9:ef:74:74:18:9b:14:c5:96:ce:70:43:18:ff:2d:
25:d6:5a:15:15:11:dc:e9:6e:98:ea:b0:1d:73:d0:
73:e2:5c:e7:f9:b8:03:a8:8d:1f:81:ca:87:97:b5:
82:3a:f2:71:15:0c:34:1f:63:8d:b8:03:99:6f:e7:
4d:c0:b7:c9:9a:63:60:10:af:7a:5b:db:df:aa:a3:
81:8e:6c:44:b0:77:ee:33:0c:00:e1:67:a8:e1:8d:
61
...
...
So, the private exponent is the 256bytes(2048bits), not the modulus, isn't it?
I've googled the following URL's and need more simple information regarding Bilinear Maps
Intro to Bilinear Maps -- by Bethencourt and
http://en.wikipedia.org/wiki/Bilinear_map
Lecture 25: Pairing-Based Cryptography -- MIT course
I would like to know in a simple to understand framework
1) what is a bilinear pairing -- an example would be great
2) how is it useful say in CP-ABE -- ciphertext policy attribute based encryption schema
Thanks
A pairing, in cryptography, is a way to make three-party operations.
Suppose that you have three groups G1, G2 and G3, in which discrete logarithm is hard. Let's note group operation additively (with a '+' sign) in G1 and G2, and multiplicatively in G3. A pairing e is a function which takes one element of G1 and one element of G2, and outputs an element of G3, such that, for all integers a and b, and all group elements X1 and Y1 (from G1) and X2 and Y2 (from G2), you get:
e(X1 + X2, Y1) = e(X1, Y1) e(X2, Y1) (pairing is linear in the first parameter)
e(X1, Y1 + Y2) = e(X1, Y1) e(X1, Y2) (pairing is linear in the second parameter)
e(aX, bY) = e(X, Y)ab (actually a consequence of the bilinearity explained above)
An example of a very weak pairing is the following: let p and q be two prime numbers such that q divides p-1. Let g be a multiplicative generator of a sub-group or order q modulo p (i.e. g is not 1, but gq = 1 mod p). Define G1 and G2 to be the integers modulo q, with addition as group operation. Define G3 to be the subgroup generated by g. Then, define e as: e(X, Y) = gXY mod p. This gives you a non-degenerate pairing ("non-degenerate" means that the pairing can return values other than 1). But it is useless for cryptography because "discrete logarithm" in G1 and G2 is a matter of a simple modular division, i.e. very easy to compute efficiently (because we used integer addition as group law).
A non-weak pairing can be used for identity-based cryptography (where the public key of someone is their email address, not some mathematical object linked to the address through a signed certificate -- the point being, precisely, to avoid a PKI). It can also be used for three-party Diffie-Hellman, or more generally protocols which involve three entities at a time (e.g. protocols for "electronic cash" or some voting systems). See this page for some details and links.
The currently only known cryptographically strong pairings, but still usable in practice, are based on specially crafted elliptic curves. See Ben Lynn's PhD dissertation for a mathematical introduction, and PBC for the implementation. An "easy" variant will make G1 and G2 an elliptic curve over a field GF(p) (for a prime integer p), and G3 will be a multiplicative subgroup of the invertible elements in GF(p2). Be warned that it is somewhat higher-level mathematics than "plain" elliptic curves (you have to know how field extensions work).