# Tag Info

1

Public-key cryptography is not sufficiently computationally burdensome to where other approaches must be used for authentication protocols. Note though that what you describe is not actually public-key based. The verification of the MAC requires Dave and Bob to both have a shared key. Also, note that a random component must be included in some manner in all ...

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 ... 2 Because the function used for RSA encryption and decryption is commutative. This means that given secret key$sk$and public key$pk$for all messages$m\$ you have that $$D(E(m,pk),sk)=E(D(m,sk),pk)=m.$$ This means that first encrypting a message with the public key and then decrypting the so obtained ciphertext with the corresponding secret key yields the ...

1

The PKCS#7 standard is a messaging standard which includes messaging formats for signed data, enveloped data or signed and enveloped data. The PKCS#11 api will produce a "raw" signature, which you will have to wrap in the PKCS#7 signed data formats. If you are using Java or .Net I would recommend looking at the Bouncycastle apis, which include full PKCS#7 ...

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).

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 ...

Top 50 recent answers are included