i have implemented RSA algo in symbian using class
CRSAPublicKey and CRSAPKCS1v15Encryptor
wheter it is rightway to implent encryption
With encryption, the devil is in the details.
There are many, many ways to get encryption incorrect. For example, with RSA, you need to use padding, or a number of easy attacks become possible. Even if you get the padding right (which, if you're using CRSAPKCS1v15Encryptor correctly, you might be), you have to defend against replay attacks, and find some way to get a trusted key. Or you might flub the comparison in the end like Nintendo did.
Rather than asking about how to do RSA, you need to consider the entire context of what you're trying to do. What are you using RSA for, and how are you using it?
Related
In OpenSSL documentation for SHA512 there's written following recommendation:
Applications should use the higher level functions EVP_DigestInit(3) etc. instead of calling the hash functions directly.
What is the reason for that? It's safer? There is no explanation why I should use IT.
I want to make SHA512 hash and according to this recommendation, I should use for computing this hash EVP_* functions instead of SHA512_* functions. Or did I understand it wrong?
SHA512_CTX m_context;
SHA512_Init(&m_context)
SHA512_Update(&m_context, data, size)
SHA512_Final(hash, &m_context);
auto m_context = EVP_MD_CTX_create();
EVP_DigestInit_ex(m_context, EVP_get_digestbyname("sha512"), NULL);
EVP_DigestUpdate(m_context, data, size);
EVP_DigestFinal_ex(m_context, hash, NULL);
I asked the same thing and here is their answer
https://github.com/openssl/openssl/issues/12260
For a number of reasons. For example:
In some cases you get sub-optimal implementations with the low-level APIs vs the EVP APIs. An example from the "cipher" world (but the same concept applies to digests) is the low-level function AES_encrypt. If you call that you will never get the AESNI optimized version which may be available on your platform.
We want to encourage applications to use a consistent API for all types of digests/ciphers etc. This makes it much easier for everyone to update code as security advice changes. For example you mention the MD5 digest APIs. MD5 is no longer recommended. It's a lot harder to update your code to use some other digest if you've used the low-level APIs vs the high level ones. Looking into the future imagine some algorithm has some major flaw discovered in it that requires a rapid migration away from it to some other algorithm. We want the OpenSSL ecosystem to be as agile as possible to be able to deal with that.
The old APIs no longer fits architecturally with how OpenSSL 3.0 works. All algorithm implementations are now made available by "providers" in OpenSSL 3.0 - for example we have the "default" provider, the "fips" provider and a "legacy" provider. The low level APIs circumvent all of that which means we have to maintain 2 ways of doing everything (3 actually when you bring ENGINEs into the picture as well). This leads to unnecessary code bloat and complexity....which is definitely something you want to avoid in a crypto library. Ideally we would have removed the old ways completely - but that would have been too big a breaking change.
I'm familiar with classical encryption algorithms and mathematics, like RSA and ECC, but just out of interest. I'm not a specialist in this field. I'd like to start a long-term project, but since I'm not a cryptographer, it's very difficult to research this topic and get a clear and correct answer. I'm looking to use OpenSSL as a black-box for this purpose.
My question: Does OpenSSL provide any post quantum asymmetric algorithms for both encryption and/or signatures?
If not, are there any plans in the future to support this?
PS: Please note that I'm not asking for software recommendation as I understand this is off-topic. I'm asking about OpenSSL here and its supported algorithms.
No, it does not.
However, you should monitor the Open Quantum Safe project, which creates a library that operates with OpenSSL with the view of introducing post-quantum safe algorithms into OpenSSL.
I am doing a project on IT security, my project involves data encryption and decryption. I have an idea of generating a truly random key which cannot be re-used using a one-time-pad. But i would not like to start from the scratch in writing the code since i am not an expert in the python programming language. I need the code which is written in python. As well as the code should be executable on windows OS. since i am using windows 7 and 8.
A true One-Time-Pad is impractical for your purpose. The key cannot be recreated at the receiving end, but must be transmitted to the receiver. Since the key is as long as the message, and must be kept secure, then you must already have a secure way to transmit something of the same length. So ignore the key and just securely transmit the message.
99% of all "improved" OTPs turn out to be stream ciphers. I suspect that your design is no different. Research stream ciphers for ideas.
You cannot generate cryptographically good randomness from a Pseudo-Random Number Generator, which is almost every computer based RNG.
In Python, you can use random.SystemRandom if your system provides the service, and it will take longer than your patience because the system takes a while to gather entropy.
For a class exercise, a OTP of 0x00000000… or 0x01020304… might be perfect for demonstration purposes. It might even be better because by-hand verification is much easier.
Indeed, an OTP of all zeros, as Randall Munroe shows is a perfectly random OTP
A truly random key is impractical and impossible to generate. What you need is a cryptographically random key. In python this can be generated by os.urandom(n) which is used by random.SystemRandom as user msw suggested.
Although creating your own random function would be the best, this should suffice.
I am writing an application which has an authenticity mechanism, using HMAC-sha1, plus a CBC-blowfish pass over the data for good measure. This requires 2 keys and one ivec.
I have looked at Crypto++ but the documentation is very poor (for example the HMAC documentation). So I am going oldschool and use Openssl. Whats the best way to generate and load these keys using library functions and tools ? I don't require a secure-socket therefore a x.509 certificate probably does not make sense, unless, of-course, I am missing something.
So, do I need to write my own config file, or is there any infrastructure in openssl for this ? If so, could you direct me to some documentation or examples for this.
Although it doesn't answer your question directly, if you are looking at this as a method of copy protection for your program, the following related questions may make for interesting reading.
Preventing the Circumvention of Copy Protection
What copy protection technique do you use?
Software protection by encryption
How do you protect your software from illegal distribution?
This is the solution I am going for atm. Unless of course someone comes up with a better one, or one that solves my specific problem.
I will put three files in /etc/acme/auth/file1 file2 and file3, binary files with randomly generates numbers for the 2 keys and the ivec, and do the same in windows but under c:\etc\acme\auth.
I'm looking for a fast asymmetric cypher algorithm to be used in C++ program.
Our application accesses read-only data stored in archive (custom format, somewhat similar to tar), and I would like to prevent any modifications of that archive by asymmetrically encrypting archive index (I'm aware that this isn't a perfect solution and data can still be extracted and repacked using certain techniques).
Some individual files within archive are encrypted with symmetric cypher and encryption keys for them are stored within archive index(header). Which is why I want to encrypt archive header asymmetrically.
Cypher requirements:
1) Algorithm implementation should be platform-independent.
2) Algorithm should be either easy to implement myself or it should be available in library (with source code) that allows static linking with proprietary application, which means that GPL/LGPL/viral licenses cannot be used. MIT/BSD-licensed code, or public domain code is acceptable.
3) If cypher is available in library, ideally it should have small memory footprint, and implementation should be compact. I would prefer to use a C/C++ library that implements only one cipher instead of full-blown all-purpose cipher collection.
Originally I wanted to use RSA, but it looks like it is simply too slow to be useful, and there aren't many alternatives.
So, any advice on what can I use?
Okay, I've found what I've been looking for, and I think it is better than OpenSSL (for my purposes, at least).
There are two libraries:
libtomcrypt, which implements several cyphers (including RSA), and libtommath, that implements bignum arithmetics. Both libraries are in public domain, easy to hack/modify and have simpler programming interface than OpenSSL, and (much) better documentation than OpenSSL.
Unlike older public domain rsa code I found before, libtomcrypt can generate new keys very quickly, can import OpenSSL-generated keys, and supports padding. Another good thing about libtomcrypt is that it doesn't have extra dependencies (OpenSSL for windows wants gdi32, for example) and is smaller than OpenSSL.
I've decided to use RSA for encryption, after all, because (to me it looks like) there are no truly asymmetric alternatives. It looks like most of the other ciphers (elgamal, elliptic curves) are more suitable for symmetric encryption where session key is being encrypted asymmetrically. Which isn't suitable for me. Such ciphers are suitable for network communications/session keys, but it wouldn't be good to use that for static unchanging data on disk.
As for "RSA being slow", I've changed archive format a bit, so now only small chunk of data is being asymmetrically encrypted. Failure to decrypt this chunk will make reading archive index completely very difficult if not impossible. Also, I must admit that slowness of RSA was partially a wrong impression given by older code I've tried to use before.
Which means, question solved. Solution is RSA + libtomcrypt. RSA - because there aren't many alternatives to RSA, and libtomcrypt - because it is small and in public domain.
OpenSSL should do the job for you. It's open-source (apache license, so meets your license requirements).
It's widely used and well tested.
Use a custom RSA to sign the archive. Store the public key in the application and keep the private key in house. Now anyone could modify the read only archive, but your application would refuse to load the modified archive.
Check out Curve25519, which is elliptic curve crytpography implemented efficiently, and around patent problems.
It meets all of your requirements. See Here.
You can use it to encrypt, or to simply sign.
As a side note:
For integrity checking, a MAC should suffice unless you really need assymetric encryption.
How about MD5?
Yes I am aware that MD5 has been 'broken; - but most practical applications this is irrelevant.
Especially if the modified data would also have to be valid in the particular data format as well as have the correct MD5
EDIT:
MD5 is appropriate if you want to just ensure that data stored can't be changed (or at least you can detect it) but it doesn't hide the data. Note that if you must have the key in your app alongside the data it can always be extracted. There are techniques for hiding the key - a popular one is simply to put it inside a static resource such as an icon that can be linked easily.