# Tag Info

10

Yes, of course there is a benefit to signing unencrypted emails. The article you cite is solely about the combination of signature and encryption; it doesn't directly say anything about signing unencrypted emails. There is an important concern raised by the article which does apply to unencrypted emails, but that's because that concern applies equally ...

8

The article you linked to predates the S/MIME 3.2 spec. If your client is sending S/MIME 3.2 messages, it should support header protection. Refer to RFC 5751 Section 3.1: In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message ...

7

Informally, a signature scheme with message recovery is one where some or all of the message is embedded in the signature, allowing to conserve bandwidth when transmitting a signed message, compared to a signature scheme with appendix. Total message recovery A signature scheme with total message recovery [some sources make total implicit, e.g. the HAC ...

6

OpenPGP as defined by RFC 4880 knows two different encodings. Binary encoding Obviously, there is no reasonable limitation to an (ASCII) character subset in binary encoding. Radix 64 Radix 64 is also often entitled ASCII armored. In the end, it is a base64 encoding with a checksum. The content may consist of [a-zA-Y0-0+/=]. ASCII-armored OpenPGP ...

6

It mainly depends on how the algorithm was selected. If it was selected by a public competition like for AES, then it is likely to be secure. If it was forced in by the NSA such as Dual-EC random number generator, then you may have some doubts. Other questions you may want to ask yourself are: Is this an "original" algorithm or was the problem that it ...

5

SafeCurves lists some ways to compare the security of elliptic curves. Their security criteria are split to "ECDLP security" and "ECC security". Failing the former basically means "there is no way to use this curve securely in general" while the latter "it is difficult to implement this curve securely". None of the (few) BouncyCastle-supported curves that ...

5

Yes! (restrictions apply). ISO/IEC 9796-2 (scheme 1, SHA-1 hash, option 1 also known as implicit hash identifier, alternative signature production function) is a fully standard signature scheme, based on RSA, widely used in the Smart Card industry for public key certificates and message authentication, that adds only 22 bytes of signature overhead (if the ...

5

Towards the security of the signature scheme, no precaution against timing attack is necessary when verifying an asymmetric signature. That's because there is no secret involved, thus no information leak to fear. However it can happen that the message, or the signature itself, is intended to be secret; a leak by timing dependency (during computation of the ...

4

You can use multi-signatures. One example is the BN06 scheme described in the paper: Bellare, Neven - Multi-signatures in the plain public-Key model and a general forking lemma

4

The benefit to signing a non-encrypted email is that any recipient can verify that it was indeed you who wrote that non-encrypted email, unless your key was compromised (or the signing protocol has an exploit).

4

$q$ does not divide $s^e-h(m)$, but $p$ does, so since the gcd must divide both $s^e-h(m)$ and $n$ it's $p$. To be even more explicit, we know that $p$ divides both $s^e-h(m)$ and $n$. The only larger divisor of $n$ that is also divisible by $p$ is $n$ itself, but if $n$ would divide $s^e-h(m)$, then $q$ would also divide $s^e-h(m)$, which we already assumed ...

4

Yes, you can, but you would need access to raw or textbook RSA encryption and you would have to implement the PKCS#1 v1.5 or PSS padding primitives yourself. Beware that PKCS#1 v1.5 compatible padding is different for encryption signature generation. If you only have PKCS#1 v1.5 encryption or OAEP encryption available then the encryption routine will ...

4

Well, if the hash function is weak, then the attacker might be able to take a valid signature for a signed message, and find a second message for which the signature for this first would also validate for the second. For example, if Alice signs the message "I like chocolate", what Bob might do is find a second message "Alice owes Bob $13,106,107.57", and ... 4 The main benefit of adding randomness in RSA signature padding is that it simplifies and strengthens security arguments. At least that's claimed by PKCS#1v2, paragraph above 8.1.1 (emphasis mine) RSASSA-PSS is different from other RSA-based signature schemes in that it is probabilistic rather than deterministic, incorporating a randomly generated salt ... 3 In general, no. There are: $${2^{64} \choose 2^n} = \frac{2^{64}!}{2^{n}!(2^{64}-2^n)!}$$ possible ways of selecting$2^n$distinct 64-bit vectors. This is a huge number; using Stirling's approximation of factorials, when$2^{n}$is substantially smaller than$2^{64}$(i.e. when$n$is smaller than$55$or so), this number of combinations is approximately ... 3 You can prove that a document was signed after a certain date by including data that was not known to anyone before that date, such as stock market data. You cannot prove that a document was signed before a certain date by purely cryptographic means. Information doesn't go stale, so when you show a signature, it could have been signed at any time. You can ... 3 This sounds like "fair exchange," the subject of many good research papers. In general you need a third party to give any security guarantees, but "optimistic fair exchange" involves the third party only when one of the parties tries to cheat (i.e., when both play honestly there is no involvement from the third party). Incidentally, Diffie-Hellman is most ... 3 Here and in many other signature schemes,$f$is modeled as a "random oracle." This means that on each distinct input,$f$outputs a uniformly random value in$\mathbb{Z}_q$that is independent of all other outputs. (When queried on the same input multiple times, it always returns the same answer.) The trick here is that the simulator has the power to ... 3 RSASSA-PKCS1-v1_5 does not use random padding, the scheme is deterministic. RSASSA-PSS is different from other RSA-based signature schemes in that it is probabilistic rather than deterministic, incorporating a randomly generated salt value. The signature is verified using a hash over the message hash and the salt. So the verifier does not ... 3 No, these sorts of attacks are not of any use against RSA -- they are much harder to perform than other existing attacks (and in particular, attacks that factor an RSA modulus). Here is how this precomputation attack works; you assume that someone generating the keys will always MAC (or sign) a specific message: $$S_i = MAC_{K_i}( FixedMessage )$$ And so ... 3 I guess the answer is no, as long as you are using ECIES then this protocol does not work - you cannot trust the public key of Bob, which is required for ECIES. You could however use ephemeral-static Diffie-Hellman, using ECDH as cryptographic algorithm. Alice would supply the static part as her public key is trusted, Bob may use any key pair. That means ... 3 If you want$N$serial numbers, your serial numbers will have to use$n$bits for uniqueness, where$n = \log_2 N$. So if you have 100 bits to use for the serial, you could use 20 to get about a million serials and have 80 bits to use for a cryptographic MAC or signature. Now there are two approaches, the symmetric and the asymmetric. In the symmetric ... 3 If you look at exact security, the height matters. The reason is that it defines the number of OTS key pairs and hence the possible number of one time signatures per MSS key pair. To forge a MSS signature, it is enough to generate a forgery for 1 out of$2^h$OTS signatures. Hence you get a reduction in the bit security of$h$bits. 3 The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and ... 3 I think you have some misunderstanding here. Finding collisions when knowing the trapdoor is a required feature, but leaking the trapoor when knowing collisions is an undesirable "feature" (which some constructions suffer from). A chameleon hash function (aka trapdoor commitment) allows you given the trapdoor to find pairs$(m,r)$and$(m',r')$with$m\neq ...

3

No, not really. Elliptic curve signatures are the smallest you'll find in common use. An $n$-bit elliptic curve produces $2n$-bit ECDSA signatures. The smallest standard curves that offer some security are 160-bit, and those are not really recommended (e.g. NIST recommends 224+ bits). That would give you 40 byte signatures. Lower than 64, but not 32. So 40 ...

3

The only way you could do this if if you could affect the padding schemes appropriately. Mathematically, textbook RSA encryption with the private key is the same as textbook RSA signature generation. Nobody should use textbook RSA, however. In practice, padding schemes are used and they differ between the two operations. So unless you can turn off padding ...

3

According to this answer, RSA with the "usual" "padding scheme, described in PKCS#1 as the 'old-style, v1.5' padding," can be made to satisfy that; one would need to specify NULL or omission and require that the public exponent's prime factors are all easily findable and sufficiently bigger than the 4th root of the modulus.

3

It is logically impossible to transfer a private key. The key will continue to be a signature key, but it will cease to be "private" the minute it is transferred. A signature key that isn't private isn't a private key. If you want the document to be signed by the user (in any semantically coherent sense), this operation has to take place on a device ...

3

To start with, it's certainly not a bad idea to avoid SHA-1 when other algorithms exist, which do not have the SHA-1 weaknesses to anyone's knowledge. The security of SHA-1 depends on how you're using it. The vulnerability is what's known as a collision vulnerability: an attacker has the ability to create two input strings with the same SHA-1 hash with less ...

Only top voted, non community-wiki answers of a minimum length are eligible