I have been reading a little bit about Encryption.
I'm currently in a project where I'll need to Encrypt/Decrypt data based on a key (user password), but the problem is:
- I'll need to encrypt/decrypt in several client applications built with different languages. Example:
- PHP
- C++
- Java
etc.
What should I do? is there any good (and free) lib that was written to different languages?
thank you
you don't need to have one-and-the-same-lib for different platforms...
as long as the choosen ciphers & keys & modes of operation are the same, it shouldn't really matter.
for example i've had no problems with AES encrypting in c# using the crypto service provider which ships with the .net framework and decrypting using the openssl module for php ...
there sometimes are some hurdles, like byteorder, encoding, etc. but if you take a closer look there's no black magic ...
Related
I want to encrypt a json data as JWE using a public key stored in HSM. I use .Net framework or .Net core libraries for Net.Pkcs11Interop.HighLevelAPI for communication with HSM.
I searched lots of sample java or .net core sample code but they all encrypted by local stored .cer/.pem keys. I only want to do this by using HSM and want to handle JWE encrypted format not a normal encrypted string result.
By default, the pkcs11Interop code wraps a PKCS11 provider. The default provider is simply a wrapper around either a minimal P11 implementation, or SoftHSM or something (I don't know). Instead, you would tell it to use the P11 provider supplied by the vendor of the HSM. Changing the P11 provider changes how the hardware is accessed, but otherwise does not change the behavior of Interop.
But other than that change, there will be no difference in the outer code (the code that is using Interop), except maybe at the user auth (C_Login in PKCS11-speak), as different vendors may have slightly different capabilities there (dual control, MFA, etc).
I would look for the HSMs provider and add that to your search terms. Possibly there is an integration guide available, assuming there is something truly weird about the vendor's Provider implementation. Most HSMs are using P11 the standards-based way (most of the Vendors are on the P11 standards committee), so assume that if an integration guide is provided, it will be very short, and very probably work with another vendor's implementation with little or no change :)
Disclosure: I work for an HSM vendor, it does work with Interop, and no, we don't have an Integration Guide dedicated to support of Interop.
I have a Pascal Script code in Inno Setup script to get the DBURI from user inputs, and save it to file, so the application can read this string and connect to database.
DBURI :=
'Databaseserver//'+DatabaseUserName+':'+DatabasePassword+'#'+
Host+':'+Port+'/'+DatabaseName+'"';
SaveStringToFile(dbconf, DBURI, True);
It works perfectly. But the problem the string not encrypted, and anyone who browses to the file can get the database password. I want to use an encryption method with a predefined key within Pascal Script code, and write the output value (encrypted string) to the file.
So, I can include the encryption method and key in my application code to decrypt value and start using DBURI string.
So, my question how to use an encryption method (anyone) with a predefined key within Pascal Script code?
I found many articles in Pascal documentations but I didn't know how to use?
Your question is rather broad, so I will answer it broadly too.
Some facts:
In general, there's no really safe way to encrypt data (the DB password), so that they can be used automatically. Even if you use an encryption key. It's not that difficult to retrieve the key from the binaries. Particularly Inno Setup code is easy to disassemble. See Disassembling strings from Inno Setup [Code]. Though as you seem to be willing to accept even plain key-less Base64 encoding, your security needs are probably not that high.
There's no support for encryption in Inno Setup (or its Pascal Script code). You have to use external functions or applications. Though some simple encoding (not encryption), like Base64, can be implemented in Pascal Script code.
What you can do:
If you will be decrypting the data using the same local account as encrypting them (the same user installs and uses the software), use Windows CryptoAPI. This is really secure, as it uses a key that associated with the local account and protected by accounts password. But that limits the use, as mentioned.
See Simple AES encryption using WinAPI.
I didn't try to implement this in Pascal Script, but I believe it should be possible.
I believe you can use CryptoAPI even with a known key (shared between the installer and the application), but I do not know details.
Another way to encrypt data with a known key is by invoking an external application for that. You can use PowerShell and .NET classes for implementing encryption. Or you can add a hidden feature to your own application, that you will call from Inno Setup to encrypt and store the data.
If you are happy with Base64 (or maybe hex) encoding, see:
Encode string to Base64 in Inno Setup (Unicode Version of Inno Setup)
I have a Java application (an ESB - Enterprise Service Bus) which deals with customer sensitive data and have a requirement of supporting Data encryption at rest in order to prevent data abuse.
The application stores customer data for processing on the file system and application interacts with it through java.io.File API. So basically, I need to encrypt the file before it is persisted on the file system by the application and then decrypt it before application reads it so that it can be parsed and processed.
Are there any good frameworks or libraries that can help me implement Data encryption at rest? I am planning to use PGP encryption/decryption for implementing Data encryption at rest.
I am looking for best and recommended approach for implementing Data encryption at rest within my Java application and any help shall be appreciated.
Why on Earth would you think pgp is the right tool for this? Seems to me that you only need a symmetric key solution, so pgp feels like the wrong answer.
Cryptography in Java is a minefield. Easy to do things wrong, hard to do things right.
Having said that, you have a better chance to not screwing up if you use BouncyCastle rather than something else. They have example code that shows you how to do various operations.
For encrypting data at rest, I recommend you use AES in either CBC mode or CTR mode. If using CBC mode, make sure you choose your IV in a cryptographic secure way (unpredictable). Also, never re-use an IV for any mode of operation.
You should also consider whether you need message integrity. General guidance about symmetric encryption here.
Even though people often get crypto wrong, the bigger problem is key management. That's a whole new can of worms (and don't be fooled into thinking pgp provides a solution to this: all it does is shifts the problem to somewhere else).
I am going to write my own encryption, but would like to discuss some internals. Should be employed on several mobile platforms - iOS, Android, WP7 with desktop serving more or less as a test platform.
Let's start first with brief characteristics of existing solutions:
SQLite standard (commercial) SEE extension - I have no idea how it works internally and how it co-operates with mentioned mobile platforms.
System.data.sqlite (Windows only): RC4 encyption of the complete DB, ECB mode. They encrypt also DB header, which occasionally (0.01% chance) leads to DB corruption.*) Additional advantage: They use SQLite amalgamation distribution.
SqlCipher (openssl, i.e. several platforms): Selectable encryption scheme. They encrypt whole DB. CBC mode (I think), random IV vector. Because of this, they must modify page parameters (size + reserved space to store IV). They realized the problems related to unencrypted reading of the DB header and tried to introduce workarounds, yet the solution is unsatisfactory. Additional disadvantage: They use SQLite3 source tree. (Which - on the other hand - enables additional features, i.e. fine tuning of the encryption parameters using special pragmas.)
Based on my own analysis I think the following could be a good solution that would not suffer above mentioned problems:
Encrypting whole DB except the DB header.
ECB mode: Sounds risky, but after briefly looking at the DB format I cannot imagine how this could be exploited for an attack.
AES128?
Implementation on top of the SQLite amalgamation (similarly as system.data.sqlite)
I'd like to discuss possible problems of this encryption scheme.
*) Due to SQLite reading DB header without decryption. Due to RC4 (a stream cipher) this problem will manifest at the very first use only. AES would be a lot more dangerous as every "live" DB would sooner or later face this problem.
EDITED - case of VFS-based encryption
Above mentioned methods use codec-based methodology endorsed by sqlite.org. It is a set of 3 callbacks, the most important being this one:
void *(*xCodec)(void *iCtx, void *data, Pgno pgno, int mode)
This callback is used at SQLite discretion for encrypting/decrypting data read from/written to the disk. The data is exchanged page by page. (Page is a multiple of 512 By.)
Alternative option is to use VFS. VFS is a set of callbacks used for low-level OS-services. Among them there are several file-related services, e.g. xOpen/xSeek/xRead/xWrite/xClose. In particular, here are the methods used for data exchange
int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst);
int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite3_int64 iOfst);
Data size in these calls ranges from 4 By (frequent case) to the DB page size. If you want to use a block cipher (what else to use?), then you need to organize underlying block cache. I cannot imagine an implementation that would be as safe and as efficient as SQLite built-in transactions.
Second problem: VFS implementation is platform-dependent. Android/iOS/WP7/desktop all use different sources, i.e. VFS-based encryption would have to be implemented platform-by-platform.
Next problem is a more subtle: Platform may use VFS calls to realize file locks. These uses must not be encrypted. More over, shared locks must not be buffered. In other words, encryption at the VFS level might compromise locking functionality.
EDITED - plaintext attack on VFS-based encryption
I realized this later: DB header starts with fixed string "SQLite format 3" and the header contains a lot of other fixed byte values. This opens the door for known plaintext attacks (KPA).
This is mainly the problem of VFS-based encryption as it does not have the info that the DB header is being encrypted.
System.data.sqlite has also this problem as it encrypts (RC4) also the DB header.
SqlCipher overwrites hdr string with salt used to convert password to the key. Moreover, it uses by default AES, hence KPA attack presents no danger.
You don't need to hack db format or sqlite source code. SQLite exposes virtual file-system (vfs) API, which can be used to wrap file system (or another vfs) with encryption layer which encrypts/decrypts pages on the fly. When I did that it turned out to be very simple task, just hundred lines of code or so. This way whole DB will be encrypted, including journal file, and it is completely transparent to any client code. With typical page size of 1024, almost any known block cipher can be used. From what I can conclude from their docs, this is exactly what SQLCipher does.
Regarding the 'problems' you see:
You don't need to reimplement file system support, you can wrap around the default VFS. So no problems with locks or platform-dependence.
SQLite's default OS backend is also VFS, there is no overhead for using VFS except that you add.
You don't need block cache. Of course you will have to read whole block when it asks for just 4 bytes, but don't cache it, it will never be read again. SQLite has its own cache to prevent that (Pager module).
Didn't get much response, so here is my decision:
Own encryption (AES128), CBC mode
Codec interface (same as used by SqlCipher or system.data.sqlite)
DB header unencrypted
Page headers unencrypted as well and used for IV generation
Using amalgamation SQLite distribution
AFAIK this solution should be better than either SqlCipher or system.data.sqlite.
I have to do some secure communication between a windows service and an asp.net website. In the asp.net website I am generating a key pair, sending my public key to my windows service and then receiving the encrypted message from my service and decrypting with asp.net.
The first problem is this.. The user profile is not created in asp.net so I must use RSAParams.Flags = CspProviderFlags.UseMachineKeyStore;.
This doesnt work in my hosting provider because I do not have access to my machine store.
I think my solution would be to generate the key pair in memory and never use the keystore, is this possible?
Checkout http://www.codeproject.com/KB/security/EZRSA.aspx Exerpt from the article:
"Help! What do we do?? A bit of Googling around, and a quick email to our (excellent) Web hosting providers Liquid Six, revealed that the reason for this lies deep inside the Windows crypt API, on which RSACryptoServiceProvider is based. Essentially, to allow scripts to load up their own private keys would compromise the security of the Windows key store, so all sensible Web hosting providers turn it off lest a rogue script steals / overwrites the hosting provider's own private keys. This strikes me as a major snafu in the Windows crypt API but there you go. I guess we're stuck with it.
Some more Googling turned up two essential resources: Chew Keong TAN's most excellent BigInteger class and some LGPL 'C' code to do the requisite calculations and PKCS#1 encapsulation from XySSL (originally written by Christopher Devine). These resources were particularly useful to me because (a) the ability to manipulate numbers with hundreds of digits is a specialist area, and (b) I hate ASN.1 (on which the PKCS#1 format is built). The calculations themselves are deceptively simple.
A day or two of stitching and patching later and EZRSA was born. EZRSA does pretty much everything that RSACryptoServiceProvider can do but entirely in managed code and without using the Windows crypt API. As a result, it will run anywhere, no matter what trust level your Web hosting provider imposes on you (which is what we needed)."
Hope it helps!