I want to add cryptography to my program and after some research on cypher algorithms i found about AES and AESWrap and my main question is, how are they related? To be honest i don't realy understand the whole process since i've never used crryptography before. At first i thought that AESWrap was the AES's decription key but it's something more than that.
I am developing a chat program in java and i want to encrypt the streams of String, so basically any outside attacker unless he knows the algorithm's process and the keys from server and client he can't get access to the stream. I thought of using Blowfish but from papers i read it appears that even though it's fast it has some problems in its rounds. Now i am digressing so to sum it all up, do i "have to" use AESWrap with AES or are those two completely different?
AESWrap is an algorithm describing a way to encrypt encryption keys. You don't need to use AESWrap to use AES. You might use AESWrap if you need to encrypt the encryption key.
If you are developing a chat program, why not use SSL/TLS to secure the communication? Using symmetric key algorithms (alone) like AES gives the problem of distributing the keys to both ends. A problem SSL/TLS solves by use of certificates.
Related
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 writing software in Java that will run on Android, Windows, Linux and OSX and want the devices to all talk to each other securely.
My initial thought was just to use a asymmetric algorithm (eg. RSA) and share the public keys manually. Then sessions would be encrypted just using RSA. I hit problems with this due to buffer size, then I read about CBC etc and the problems of data leakage if some form of XOR of data was not performed.
So...I looked at using AES/CBC/{padding}. Initially this sounded good: just share the key, an IV and away we go.
But these apps all talk to each other in both directions at any time, so keeping the IV in sync did not seem possible, resulting in a new IV being sent with every message. Not a big deal, but one of the advantages of AES over RSA is data size, and now I'm going to be adding 32 bytes to every message. Though I guess keeping a 'receiver' and a 'sender' Cipher would probably work.
Now I am back to considering alternatives, and trying to avoid too much roll-your-own.
Is there any substantial reason not to use RSA and CBC (or similar) done manually? ie. break data into chunks, pad as necessary, and encrypt with RSA, doing whatever XOR strategy seems most reliable.
Is there a better was to keep secure and trusted comms between pairs of peers without creating an SSL CA? Or, is there a way of hooking into the certificate verifier so that I can use my pre-shared public keys to validate the peer connections?
Any other suggestions/examples for best/simple multi-platform peer-peer secure comms?
You should look into implementing a hybrid cryptosystem. If I can guess your knowledge about the subject correctly you should really be using a pre-existing one like TLS, or DTLS, as you're not going to design a cryptographically safe protocol out of the blue.
Note that the certificates are required to create a PKI, and the asymmetric crypto of course comes with it. You should however only have to use the asymmetric crypto during the handshake which includes the initial authentication and session key negotiation.
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.