Difference between revisions of "Security"
| Line 5: | Line 5: | ||
=== security questions and answers === | === security questions and answers === | ||
| − | + | ==== You use SHA256 hashcodes to find the message-keys in the clearing database. Isn't there a high risk in collisions that may leak security? ==== | |
| − | + | If we have a "perfect" hash function with output size n, and we have p messages to hash (individual message length is not important), then the probability of a collision is about p<sup>2</sup>/2<sup>n+1</sup> (this is an approximation which is valid for "small" p, i.e. substantially smaller than 2<sup>n/2</sup>). For instance, with SHA-256 (n=256) and one billion messages (p=10<sup>9</sup>) then the probability is about 4.3*10<sup>-60</sup> (0.0000000000000000000000000000000000000000000000000000000000043%). | |
Additionally, the message is not only compared against the message-hashcode. The recipients hashcode needs to match perfectly to this transaction, too. Upon this, the risk of a collision is very very low... | Additionally, the message is not only compared against the message-hashcode. The recipients hashcode needs to match perfectly to this transaction, too. Upon this, the risk of a collision is very very low... | ||
| Line 13: | Line 13: | ||
| − | + | ==== You use 1024 bit RSA keys for identity-file and securing clearing-communication. Isn't the length of 1024 bit too less? ==== | |
| − | + | You need to keep in mind, that the regify-system ''does not encrypt the messages itself using these RSA keys''. The messages are getting encrypted using AES256 and the message-key is stored directly in the clearing-service. | |
The RSA encryption is used for two purposes: | The RSA encryption is used for two purposes: | ||
# Securing the communication between regify-client and clearing. In this case, the encryption needs to "hold" only for the duration of of the communication process. Additionally it needs to "hold" for the time a attacker is willing to spend to break it. | # Securing the communication between regify-client and clearing. In this case, the encryption needs to "hold" only for the duration of of the communication process. Additionally it needs to "hold" for the time a attacker is willing to spend to break it. | ||
| Line 22: | Line 22: | ||
| − | + | ==== Why don't you use PKI techniques and standards like S/MIME or PGP? ==== | |
| − | + | regify does not work as PGP or other PKI methods. The benefits of the regify-system would not have been possible, if we would use these standards. The benefits, that are resulting directly on the abstinence of standard PKI techniques, are: | |
* regify is much easier to understand, to administrate and to handle. | * regify is much easier to understand, to administrate and to handle. | ||
* regify generates a confirmation of receipt. | * regify generates a confirmation of receipt. | ||
| Line 32: | Line 32: | ||
* in the regify portal, you can manage representatives. Thus, a user can have his important e-mails processed in a controlled manner during his absence. | * in the regify portal, you can manage representatives. Thus, a user can have his important e-mails processed in a controlled manner during his absence. | ||
* and many others... | * and many others... | ||
| − | |||
== code signing certificate == | == code signing certificate == | ||
Revision as of 18:20, 4 March 2013
Contents
- 1 Security
- 1.1 security questions and answers
- 1.1.1 You use SHA256 hashcodes to find the message-keys in the clearing database. Isn't there a high risk in collisions that may leak security?
- 1.1.2 You use 1024 bit RSA keys for identity-file and securing clearing-communication. Isn't the length of 1024 bit too less?
- 1.1.3 Why don't you use PKI techniques and standards like S/MIME or PGP?
- 1.1 security questions and answers
- 2 code signing certificate
Security
This article is intended to answer the questions of security experts that like to have a deeper look at the regify-service. If you are an expert having additional questions, please feel free to send us an e-mail at info (at) regify.com (subject "security questions").
security questions and answers
You use SHA256 hashcodes to find the message-keys in the clearing database. Isn't there a high risk in collisions that may leak security?
If we have a "perfect" hash function with output size n, and we have p messages to hash (individual message length is not important), then the probability of a collision is about p2/2n+1 (this is an approximation which is valid for "small" p, i.e. substantially smaller than 2n/2). For instance, with SHA-256 (n=256) and one billion messages (p=109) then the probability is about 4.3*10-60 (0.0000000000000000000000000000000000000000000000000000000000043%). Additionally, the message is not only compared against the message-hashcode. The recipients hashcode needs to match perfectly to this transaction, too. Upon this, the risk of a collision is very very low...
Reference: http://en.wikipedia.org/wiki/Birthday_Paradox
You use 1024 bit RSA keys for identity-file and securing clearing-communication. Isn't the length of 1024 bit too less?
You need to keep in mind, that the regify-system does not encrypt the messages itself using these RSA keys. The messages are getting encrypted using AES256 and the message-key is stored directly in the clearing-service. The RSA encryption is used for two purposes:
- Securing the communication between regify-client and clearing. In this case, the encryption needs to "hold" only for the duration of of the communication process. Additionally it needs to "hold" for the time a attacker is willing to spend to break it.
- Used as Private/Public key pair in the regify identity-file. This one is used to ensure the authentication of the user against his regify-provider. Additionally, the communication between the regify-client and the regify-provider is secured by this keys. As the messages itself are not associated in any way with this identity-file, the identity-file can get renewed as often as the customer likes to. Upon this, the same answer as on 1. is adequate here. Furthermore, the used algorithms and bitlength can get changed at any time in the future - without having any effect on the message accessibility.
Upon these facts, and contrary to PKI solutions, using 1024 bit for RSA enryption is an ideal compromise between security and speed. Anyhow, each provider is able to raise the bitlength up to 2048, 3072 or 4096 bits for his individual preference.
Why don't you use PKI techniques and standards like S/MIME or PGP?
regify does not work as PGP or other PKI methods. The benefits of the regify-system would not have been possible, if we would use these standards. The benefits, that are resulting directly on the abstinence of standard PKI techniques, are:
- regify is much easier to understand, to administrate and to handle.
- regify generates a confirmation of receipt.
- regify transactions are traceable and auditable at any time (history).
- you only have to know a persons email address to be able to send her a regify e-mail.
- you don't need to actualize certificate revocation lists, manage trust-center certificates or any other certificate servers.
- in the regify portal, you can manage representatives. Thus, a user can have his important e-mails processed in a controlled manner during his absence.
- and many others...
code signing certificate
The regify setup files and some included exe and dll files are digitally signed using a regify code signing certificate. It is issued by Comodo, which is very well known as a reliable and very secure certificate issuer.
Comodo still secure?
On March 15, 2011, Comodo reported that a user account with an affiliate registration authority had been compromised which was used to create a new user account that issued nine certificate signing requests. Nine SSL certificates for seven domains were issued: mail.google.com, login.live.com, www.google.com, login.yahoo.com (three certificates), login.skype.com, addons.mozilla.org, and global trustee. These certificates are officially revoked and the code signing certificates are not affected by this breach. The root certificates have not been affected and all other Comodo certificates remain secure.
