I want to know if our data is encrypted with one encryption algorithm(AES, DES, etc.) and then we transfer our data in open network, can anyone get real data or do some thing if the encryption algorithm is known even though the hacker doesn't know about the private keys, public key or PV?
can anyone get real data or do some thing if the encryption algorithm is known
If the attacker knows the encryption algorithm, it's a start, because now all they need to do is to find out what was the key used to encrypt it. But established encryption algorithms like AES have no known weaknesses. Thus an attacker would be forced to bruteforce it to gain access to the data.
If you are using keys of an appropriate size (eg: AES 256 bits or more), this would be a very difficult task. DES also has no known weaknesses, but its small key size (56 bits) allows for a bruteforce attack to succeed in a reasonable timeframe, (eg: days). That's why DES is not widely used any more.
even though the hacker doesn't know about the private keys, public key or PV?
Note that public keys are only relevant in the context of asymmetrical encryption. In this case, the public key is usually publicly available (hence, the name "public key"). But asymmetric encryption is designed so that even if you know the public key, you can't decrypt it unless you have the private key.
In summary, encryption algorithms like AES have stood the test a time and proven to be secure enough. As David Schwartz points out in his answer, if you have a problem, (usually) your implementation is the thing to blame, not the encryption algorithm.
Almost by definition, if the encryption is implemented properly and part of a sensibly-designed system, no. That's the whole point of encryption.
Note that encryption is not magic. It must be used precisely correctly to provide useful security. There are a lot of ways to do it wrong.
If you're not using a widely respect product (like TrueCrypt, Firefox, or GPG) and using it precisely how it's intended to be used, there's a very good chance you aren't getting real security. For example, Dropbox used AES, but a security flaw in another part of their system allowed one user to decrypt another user's data. So it didn't help that it was encrypted.
Yes, keeping the algorithm secret helps security marginally. If an attacker knows that you used DES (which isn't terrifically hard to break) they may be more likely to try to break it.
I think the core of your question is about statistical attacks, which tries to see through the encryption to decipher the nature of the data. Any reasonably modern algorithm is mathematically designed to thwart any attempts to guess what the data is.
However David makes a very good point. Even perfect encryption (if it existed) would be vulnerable to the human factor. These algorithms are worthless if you don't dot your i's and cross your t's, and have absolute (and justified) faith in those who can decrypt the data.
Related
Problem
We want to encrypt personally identifiable information. They should not be readable. However, because the results will also be used for machine learning, each time a value (say "ABC") gets encrypted, the resulting data should be the same.
Most encryption ciphers include a initialization vector. This goes against what we need. To be clear, the data is supposed to be encrypted, yet this doesn't need to be bullet proof. The data is never transferred outside of the organization and this is simply done to adhere to GDPR.
Context
We have decided to use bouncy castle because it supports a large number of encryption modes, including the (apparently fast ECC). Since we are talking about encrypting several TB a day, it would be nice to have good performance.
Solution issues
Although the bouncy castle library is well written, it seems difficult to find good documentation and usage examples on it. I am struggling to find my entrypoint. Do I have to look at the org.bouncycastle.crypto, or org.bouncycastle.crypto.engines package? or the crypto.ec? I found the ZeroBytePadding class which I believe should point me to a potential engine that does what i want but I cannot find what I am looking for.
Goal
A class that has a set of methods similar to this:
class Anonomyzer{
def initialize(publicKey: String, privateKey: String): Unit
def encode(data: Array[Byte]): Array[Byte]
def decode(data: Array[Byte]): Array[Byte]
}
The following code should be true
Anonomyzer.initialize("PUBLIC", "PRIVATE")
val once = Anonomyzer.encode(data)
val twice = Anonomyzer.encode(data)
Arrays.equals(once, twice)
Edit:
I've read more on this and found that what I am looking for is called
Electronic Codebook mode of operation. Although this is not perfectly secure, this is the best we can hope for AFAIK.
However, because the results will also be used for machine learning, each time a value (say "ABC") gets encrypted, the resulting data should be the same
You may have more options than that. It is stil safer to properly encrypt data where they need to be encrypted. You may have different datasets for different purposes.
Just suggestions:
you may anonymize the learning dataset, stripping data of their PII and aggregate them to reasonable level, still valuable for ML. I'd prefer this option because then it's clean without risking to breach any rules or leaking protected information
you may hash PII (or categorical data), which would provide unique mapping without reversable mapping (though there will be always mapping from the original values)
for quantitative data you may search up "order preserving encryption" which may not be trivial to do properly (that's one of reasons why I'd go for the 1st option)
Taking shortcuts (using ECB or static IV) may in some cases completely break the security of encrypted data. So until you really know what are you doing, you may shoot yourself in your leg
We have decided to use bouncy castle because it supports a large number of encryption modes, including the (apparently fast ECC)
I'd say - you don't needed the BC library. It is a very well written library, but in your case I don't see any specific need for it.
apparently fast ECC). Since we are talking about encrypting several TB a day, it would be nice to have good performance
ECC is still asymmetric encryption usually used for hybrid encryption (encrypting a symmetric data encryption key). So if you aim for speed, you may use check that your JVM and VM allows native AES-NI support or use some fast cipher (salsa,..). Encryption is usually not the performance bottleneck if done properly
I am struggling to find my entrypoint.
In most of the cases you may use default Java crypto API with specified provider
Security.addProvider(new BouncyCastleProvider());
...
Cipher cipher = Cipher.getInstance("AES/OFB/NoPadding", "BC");
or
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding", "BC");
Edit: fixed padding combinations
I want to use A-symmetric encryption for my application.
The application basically takes a photo and sends it to a server, I haven't written any code yet and am just going through this as a POC.
I came across a problem that I solved before but now it's puzzling me again.
Like I said I want to use Asymmetric encryption where the private key is located on my server, and the public key is stored locally and 'shipped' with each android app (I.E. including in its resources). I want to use the public key along with a ByteOutputStream or EncryptedOutputStream and send the information already encrypted to the server for decryption on site.
My question is basically how safe is the process of encrypting the data i'm sending out to the server? Obviously I understand that there is no such thing as completely safe, but is this a good practice, is there something that's sort of an industry-standard?
Copypaste from this answer regarding asymmetric cryptography.
The currently largest broken RSA key is a 768-bit modulus, and it took some huge effort (four years, and really big brains). 1024-bit keys are considered usable for short term security, although larger keys are encouraged. 2048-bit keys are appropriate. Using a key twice larger means 8 times more work for signing or decryption, so you do not want to overdo it. See this site for a survey of how RSA key length can be related to security.
ECDSA over a 256-bit curve already achieves an "unbreakable" level of security (i.e. roughly the same level than AES with a 128-bit key, or SHA-256 against collisions). Note that there are elliptic curves on prime fields, and curves on binary fields; which kind is most efficient depends on the involved hardware (for curves of similar size, a PC will prefer the curves on a prime field, but dedicated hardware will be easier to build with binary fields; the CLMUL instructions on the newer Intel and AMD processors may change that).
I am trying to implement RSA encryption using blocks to cut down the run time of decrypting with large bits lengths. The way my program is now, it works but reads individual characters and decrpyts them. So as you might imagine, the run time for large bit lengths is long.
Is there a way to easily implement decryption using blocks so that it works faster for these large bit lengths. Examples of code with an implementation would be nice if it is easy and feasible. Thanks.
From your description, it appears that you're using the following encryption scheme:
for i=0 to length(input):
output(RSA_encrypt(key, input[i]))
This is not a secure encryption scheme. You appear to be asking for a way to do something similar to
for i=0 to blocks(input):
output(RSA_encrypt(key, block(i, input)))
That is likewise not secure. Secure RSA-based encryption schemes generally involve encrypting a unique session key with RSA then encrypting the message using a symmetric cipher such as AES. For instance, see RSAES-OAEP. Don't try implementing it yourself, because you're likely to get it wrong. Instead, use a reputable cryptographic library.
Always remember the Rules of Crypto:
Never design your own crypto.
Never implement your own crypto.
Anyone can design crypto that they can't break themselves.
I want to send secure data(strings) from a client to a server. This is what i think i want to do:
Turn the string into a byte array
"scramble" the bytes by putting them out of order in a specific way
Serialize array of bytes inside of a class
send the Encrypted and Serialized class to the server
then the server would:
Deserialize the class
get the bytes for the string
put the bytes in the right order
make a string out of the bytes
would this be a good way to Manually Encrypt data? Is this secure? Is it even worth the time trying to make a manual encrypter?
It sounds like you're trying to roll your own symmetric encryption scheme, using a fixed key (the "specific way" you're scrambling the bytes) known to both sides. There's no advantage to doing this over simply using a build-in encryption scheme with a known key, and substantial potential disadvantages. It takes just a small implementation mistake to create an opening that malign users can exploit.
Unless you do encryption for a living, you can't do better than what's out there, known, and proven in the field (AES is a good start). If security is important to you, don't try. If you want to experiment as a hobby, though, have fun.
Would this be a way to encrypt the data?
If you're just "scrambling" the data, no. It would be "trivially possible" to reconstruct the plaintext if it's just being scrambled. (This means the first time someone wants to read the data, they probably will, but if they're not trying too hard, they won't stumble across it by accident.)
On the other hand, if you're then running a "real" encryption algorithm over it, the scrambling adds a negligible degree of difficulty to the decryption, but you're relying upon a simple scrambling being sufficient to slow down someone who's just cracked the "real" encryption, which seems unlikely to be worthwhile.
You'd probably do far better to stick with a well-tested encryption mechanism designed by someone who does math with very large prime numbers for a living. Java's encryption framework lets you fairly easily implement a public/private key system, or a double-blind key exchange system; for example, you can just use HTTP-SSL for data exchange without much set-up on your part.
No, jumbling is not very goood. For a simple scheme you can build on check out the XOR operator.
I am programming some server-client software and wanted some encryption. Both the server and client share a private key which is fixed length. Haven't decided what length I am going to have the key, but I do know that the key will be between 1 and 32 characters. The key is predetermined (so for instance I may decide I want the key to be abc1234)
I am programming in Java and need the algorithm to be a quick as possible as the clients are most likely to be mobile devices. I don't need any compression but I would prefer if the encrypted string wasn't larger.
I am not looking for top-notch encryption here obviously, but it is my understanding that any key based encryption can't be broken without knowledge of the private key anyway.
Can anyone recommend me an algorithm/method for encryption/decryption with a shared private key?
it is my understanding that any key based encryption can't be broken without knowledge of the private key anyway
That's not even close to true. A lousy algorithm absolutely can be broken without knowledge of the private key.
Anyhow, if there's a shared key, consider AES.
And read up on the JCE/JCA as Java can do AES and other types of encryption out of the box. Much better than rolling your own.