Thomas Pornin
Reputation
37,852
121/100 score
 Feb 2 comment Is RSA of a random nonce with no padding safe? @Gilles: if padding is deterministic, and you encrypt the same $K$ (padded to $\pi(K)$) for three different recipients, with $e = 3$, then you send the value $\pi(K)^3$ modulo $n_1$, $n_2$ and $n_3$. By the Chinese Remainder Theorem, this is sufficient to rebuild $\pi(K)$ modulo $n_1n_2n_3$, and since $\pi(K) \lt n_i$, the modulo disappears. This is the historical justification for using $e = 65537$ instead of $e = 3$, but the real issue is that a deterministic padding for RSA encryption is definitely unsafe. You MUST have a random padding. Feb 2 awarded encryption Feb 1 answered Is RSA of a random nonce with no padding safe? Feb 1 answered How can I convert a DER ECDSA signature to ASN.1? Feb 1 awarded Good Question Feb 1 awarded Nice Answer Jan 30 comment Salts, how does the script know what the salt is? Actually, for most password-related salt usages, what we need is just that salt values are distinct from each other. Unbiased selection in a big enough space is sufficient to achieve uniqueness. Dates are not bad as themselves -- as long as you never choose two salts during the same second, and you take care never to repeat dates, even when the system administrator resets the clock. Jan 27 comment What is the best way to send two floating point numbers to a server on the internet from a small device such as an arduino? @DavyLandman: what I described is a single block encryption, which does not use any encryption mode -- it provides the desired properties only because it is a single block encryption, and has the specific format and rules that I mandate. CBC encryption handles longer messages but does not provide a MAC by itself; and CBC requires an IV which MUST be selected randomly and uniformly, and a new IV MUST be generated for each message. CBC is needy. I suggest you investigate EAX, which includes a MAC and has lighter IV needs (a counter suffices). Jan 27 awarded Nice Answer Jan 26 comment What is the best way to send two floating point numbers to a server on the internet from a small device such as an arduino? @DavyLandman: without some kind of memory, there is no way for the device to send messages which will resist malicious reordering by Eve -- unless you go with a two-directional protocol, in which the server interactively exchanges messages with the device: at that point, things become really complex, both to implement and to analyze. Jan 26 revised What is the best way to send two floating point numbers to a server on the internet from a small device such as an arduino? edited body Jan 26 answered What is the best way to send two floating point numbers to a server on the internet from a small device such as an arduino? Jan 25 reviewed Approve Stretching a random seed to maximize entropy Jan 25 answered Stretching a random seed to maximize entropy Jan 22 comment Calculating private keys in the RSA cryptosystem Actually it is not strictly necessary that $d*e = 1 \mod \phi(n)$; it suffices that $d*e = 1 \mod (p-1)$ and $d*e = 1 \mod (q-1)$, which is a bit less restrictive. Here, this implies that $d = 17 \mod 100$ and $d = 269 \mod 432$. The smallest matching value is $d = 6317$, which can be verified to do the RSA thing properly -- and yet, it does not fulfill the $d*e = 1 \mod \phi(n)$ equation. Jan 22 answered Use of salt to hash a password Jan 20 answered How to construct encrypted functions (with either public or private data)? Jan 20 comment RSA with small exponents? @owlstead: we use $65537$ mostly out of Tradition. The "attacks" with $e = 3$ are due to the lack of padding, and lack of padding is already a much bigger worry than that: to have an actual weakness due to $e = 3$ (compared to $e = 65537$), you have to thoroughly damage the algorithm (remove the padding step), which creates a bunch of other much bigger weaknesses. With proper padding, no problem with $e = 3$. However, I use $65537$ by default because it avoids questions, and it is not bad either. Jan 20 comment A simple block cipher based on the SHA-256 hash function And to say things more generally, that kind of stream cipher is secure only if the stream would be a good PRNG. A PRNG should not allow recomputing its internal state from its output (because knowing the state implies being able to predict subsequent output, and a secure PRNG must offer prediction resistance). It is doable with hash functions, but needs more effort. See NIST SP800-90 for some hash-based PRNG (Hash_DRBG and HMAC_DRBG). Jan 18 awarded Nice Answer