What is the difference between s/mime ,tsp and pgp? Reference : Bouncycastle.
Bouncycastle has packages for all of them, just don't understand what is the difference and what is the purspose of each package
S/MIME means Secure/Multipurpose Internet Mail Extensions. It is a standard for public key encryption and signing of MIME data. Mostly used in email. It uses certificate authorities issuing certificates for users, similar to how SSL certificates work.
PGP means Pretty Good Privacy. It is a data encryption and decryption software that provides cryptographic privacy and authentication for data communication. It follows the OpenPGP standard. Also used in email, among other things. It uses a decentralized network of trust. No certificate authorities.
TSP is a lot of things.
In addition to Zed's answer, TSP stands for Timestamping protocol, defined in RFC 3161. As is this protocol is not very usable. It's used as a third-party proof of signing time in CMS, CAdES, PDF signatures, PAdES and XAdES. Note, that Authenticode doesn't use TSP for timestamping (another format is used).
Both S/MIME and the PGP mail system uses the hybrid cryptography.But they use different formats for key exchange. Wile PGP depends upon each user’s key exchange, S/MIME uses hierarchically validated certifier for key exchange.PGP was developed to address the security issues of plain text messages. But S/MIME is designed to secure all kinds of attachments/data files. currently S/MIME dominates the modern mail system due to the complexity of implementing PGP mail system. i can not say anything about TSP before knowing further details about it.
Related
Looking at LetsEncrypt FAQ page, they have clearly stated that email encryption and code signing require a different type of certificate and therefore they are not supported by LetsEncrypt.
My understanding is that https and S/MIME both require X.509 certificates. What is the difference between certificates these two technologies require?
Among other things (like the encryption key), an X.509 certificate also specifies what it may be used for. X.509 certificates for HTTPS and S/MIME usage basically have different usages.
The structure of an X.509 certificate is fairly complex. Its possible usage depends on attributes and extensions within the certificate, and require that specific combinations of them with specific values must be present.
For example, an S/MIME certificate, requires a Key Usage attribute with something like Encrypt, Verify, Wrap, Derive, a Key Usage extension that must have the Critical attribute set to Yes and include a Usage attribute with Key Encipherment plus in the Extended Key Usage extension (sic!) it should list the Purpose attribute value Email Protection.
Note that Key Usage extension Data Encipherment is not required, because in S/MIME, the data contents are encrypted by a random symmetric key which then is encrypted with the private key from the certificate. This is called hybrid encryption and it is done for performance and scalability reasons.
The certificate requirements even extend into the certificate chain, meaning that the certificate must be signed by another certificate that has been issued to sign certificates for that usage.
Note that the above example may not be 100% correct, because the subject is so complex, and I don't fully understand every aspect of it myself. I found this quote which I think describes the situation fairly well:
I think a lot of purists would rather have PKI be useless to anyone in
any practical terms than to have it made simple enough to use, but
potentially "flawed". — Chris Zimman
Resources that helped me:
X.509 Style Guide by Peter Gutmann: an attempt to shed light on the relations of attributes and extensions and their interpretations
RFC 4262 - X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
I am not an expert (not even a novice :))) in security certificates and such - thus the question - but I was wondering if one can generate a new certificate by using a known fingerprint? :D (lost my certificate for a google play app and was wondering about this workaround)
Thanks.
This is practically impossible. The fingerprint uses a cryptographic hash like SHA-1 or SHA-256. With current technology it is impossible for a normal user to create the input which results in a specific hash value. It is doable with lots of efforts (i.e. still very very expensive) when MD5 was used for the fingerprint (not common), it might be doable by the NSA for SHA-1 and it is considered impossible to do it today for SHA-256.
Apart from that certificates are commonly not validated by the fingerprint but because a trusted CA has signed this certificate. This signature is part of the certificate so that you would not only need to recreate the certificate but also somehow get a valid signature which is impossible without having the private key of the CA which of course you don't.
I checked similar posts but I think the problem here maybe slightly different.
The problem is to provide secure communication between two peers (e.g., A and B) who may not have, how to say, "strong coupling" before (like A has its public key saved on B, that kind of thing).
The trust is based on a common signalling server who does the initial authentication (e.g., XMPP). Suppose A and B both login to that server. How would they proceed with secure and direct communication? I guess relevant keywords, using the XMPP example, would be XMPP secure socks5 (so far, this topic is uncovered in doc). Thank you for your suggestion on how I could start to implement, preferably using available library with less amount of work.
One protocol to look at is Off the Record, which has been used with XMPP in quite a few projects. The challenge you will have is how the users authenticate to each other, in a way that resists man-in-the-middle attacks. OTR uses Diffie-Hellman to exchange an AES key for bulk encryption and SHA256-HMAC. Users can then authenticate each other using a shared secret (like a passphrase), or compare public key fingerprints out of band.
I don't know if it counts as "strong coupling", but the other approach is to use certificates signed by a trusted 3rd party. If A has a certificate signed by you, and B has a certificate signed by you, then A and B can communicate securely without needing eachothers keys a priori.
I was arguing about an S3 like aproach using authorization hash with a secret key as the seed and some data on the request as the message signed with hmac sha1 (Amazon S3 way) vs an other developer supporting symetric encryption of the data with a secret key known by the emiter and the server.
What are the advantage of using signed data with hmac sha1 vs symetric key other than the fact that with the former, we do not need to encrypt the username or password.
What would be the hardest to break ? symetric encryption or sha1 hashing at la S3 ?
If all big players are using oauth and similar without symetric key it is sure that there are obvious advantages, what are those ?
An hmac and a symmetric cipher are not mutually exclusive ideas. In fact AES-CMAC which is both an MAC (not hashed) and a symmetric cipher, AES-CMAC is the cryptographic primitive that makes WPA secure. (Although a WPA can still be broken using a rainbow table).
You should not need an exotic authentication system for this. Logging in with a username and password and maintaining session state with a cookie is commonly used because it is easy to implement and it is secure. By storing state, like a cookie its no longer technically RESTful, but there is nothing stopping you from doing it.
However, in terms of authentication I believe that asymmetric cryptography like RSA is the most secure. (Amazon uses asymmetric cryptography for ssh connections by default.) This allows you to only store the public keys, so that if your server where to be compromised no authentication credentials could be used. It also defends against MITM attacks. In many cases this can be implanted quite easily with REST because HTTPS already supports client certificates. You can sign the clients certificates for free and then verify them your self.
If implemented properly, the strength of an hmac vs symmetric cipher it mostly comes down to the strength of the secret. If you are using a secret like a password, then both systems are equally very weak. These secretes must be large, Cryptographically Secure Psudorandom Numbers. Another thing to keep in mind is that symmetric ciphers are very difficult to implement properly. Most programmers do not understand this and end up reusing PRNG when using stream cipher or when using a block cipher they use an incorrect mode and leave the IV null. By contrast HMACS are very easy to implement and less can go wrong. If everything is transmitted over HTTPS, and your are using an hmac then its easy to implement a secure authentication system. If you really want to implement a symmetric cipher you must get a copy of Piratical Cryptography, there are a few chapters devoted to symmetric ciphers alone because so much can go horribly wrong. You also have to take key distribution into consideration, ssl uses a DH-Key Exchange for its symmetric keys.
Make sure to read the OWASP top 10, especially Broken Authentication and Session Management. This requires the use of https for the entire session, most web application programmers don't realize this.
The big differences would be that HMAC would provide integrity but no privacy, while encryption would provide privacy without integrity. Many use cases would require both, but I can't think of any where integrity is unnecessary. HMAC seems like a minimum requirement, with encryption being a likely companion.
Question for all the SSL experts out there:
We have an embedded device with a little web server on it, and we can install our own SSL self-signed certificates on it. The client is written in .NET (but that doesn't matter so much).
How can I authenticate the device in .NET? Is it enough to compare the fingerprint of the certificate against a known entry in the database?
My understanding is that the fingerprint is a hash of the whole certificate, including the public key. A device faking to be my device could of course send the same public certificate, but it couldn't know the private key, right?
Or do I have to build up my own chain of trust, create my own CA root certificate, sign the web server certificate and install that on the client?
What you propose is in principle ok. It is for example used during key signing parties. Here the participants usually just exchange their name and fingerprints of their public keys and make sure that the person at the party really is who he/she claims. Just verifying fingerprints is much easier than to verify a long public key.
Another example is the so called self certifying file system. Here again only hashes of public keys get exchanged over a secure channel. (I.e. these hashes are embedded in URLs.) In this scheme the public keys don't have to be sent securely. The receiver only has to check that the hash of the public keys matche the hashes embedded in the URLs. Of course the receiver also has to make sure that these URLs come from a trusted source.
This scheme and what you propose are simpler than using a CA. But there is a disadvantage. You have to make sure that your database with hashes is authentic. If your database is large then this will likeley be difficult. If you use CAs then you only have to ensure that the root keys are authentic. This usually simplifies the key management significantly and is of course one reason, why CA based schemes are more popular than e.g. the self certifying file system mentioned above.
In the same way you wouldn't and shouldn't consider two objects to be equal just because their hash codes matched, you shouldn't consider a certificate to be authentic just because its fingerprint appears in a list of "known certificate fingerprints".
Collisions are a fact of life with hash algorithms, even good ones, and you should guard against the possibility that a motivated attacker could craft a rogue certificate with a matching fingerprint hash. The only way to guard against that is to check the validity of the certificate itself, i.e. check the chain of trust as you're implying in your last statement.
Short:
Well in theory you then do exactly what a Certificate Authority does for you. So it should be fine.
Longer:
When a Certificate Authority signs your public-key/certificate/certificate request it doesn't sign the whole certificate data. But just the calculated hash value of the whole certificate data.
This keeps the signature small.
When you don't want to establish your own CA or use a commercial/free one -
by comparing the fingerprint with the one you trust you'll gain the second most trustworthy configuration. The most trustworthy solution would be by comparing the whole certificate, because also protects you from hash collision attacks.
As the other guys here stated you should make sure to use a secure/safe hashing algorithm. SHA-1 is no longer secure.
more detailed informations to this topic:
https://security.stackexchange.com/questions/6737
https://security.stackexchange.com/questions/14330