I want to discuss about openssl write and read method. Assume I have an data structure like below:
/-----------------------------------------------------\
| my_header | PAYLOAD |
\-----------------------------------------------------/
| |
\ / \ /
not encrypted encrypted
I think the proper algorithm would be like this :
SEND:
build my_header with my own header.
encrypt PAYLOAD with encryption function
attach my_header and PAYLOAD (encrypted) to one buffer
send it using common POSIX function just like send or sendto
RECV:
using common POSIX function just like recv or recvfrom.
extract my_header and PAYLOAD(encrypted)
decrypt PAYLOAD with decryption function
at last i got my_header and PAYLOAD(decrypted).
How is your approach if you face a problem like above. Since openssl encrypt all of data that is sent to SSL_write function (CMIIW).
Thanks.
Maybe, the apropriate question is, what is the encryption and decryption function that can be used to encrypt/decrypt PAYLOAD in openssl?.
You can actually let OpenSSL do a lot of the heavy lifting for you.
You can create your networking primitives as before and associate the file descriptors with an Open SSL context, which will handle the SSL handshake, encryption and decryption. I'm glossing over a lot of the details but the sample code on the openssl website and in this book:
http://www.amazon.com/Network-Security-OpenSSL-John-Viega/dp/059600270X
will be very instructive. The book is also available online but I believe you have to pay to access it.
In OpenSSL's distribution you can find lots of sample code illustrating exactly how to do this.
Good luck.
OpenSSL comes with a libcrypto library which is commonly used to perform standalone encryption outside of an SSL context.
http://www.openssl.org/docs/crypto/evp.html
Alternatively, the bio portion of the library may be even closer to what you want:
http://www.openssl.org/docs/crypto/bio.html
But if you really intend to send this over the network, then I would question the safety of leaving the header unencrypted. Encryption is about more than privacy, it is also about ensuring the data has not been modified in transit. If someone is in a position to monitor your traffic, then they are usually in a position to tamper with it too.
If you want the header unecrypted so you can read it in wireshark for debugging, then I suggest making a flag in your application to fully enable/disable encryption for use in a debugging environment.
If you're building an encrypted protocol, that's exactly how I'd do it, assuming my_header contains enough information and nothing that in itself needs to be kept secure, such as the session key. Network packets at the low level (see tcpdump/libpcap) are just a char* ("string") and you extract different headers by moving along the array different lengths - what you're suggesting sounds just like this.
When you use TLS/DTLS, you have the choice : you cipher the whole frame, or nothing at all.
If you want to have some unciphered data in the frame, then you probably don't need TLS/DTLS. You might however use OpenSSL to compute a hash of your header (using SHA or any other related hash algorithm) and adding it at the end of the frame to avoid tampering.
For the ciphered part of the frame, you'll have to choose between symetric and asymetric cipher algorithms. But without knowing what you want to achieve, I cannot really advise on this.
Just keep in mind that symetric algorithms are usually faster but require a key exchange at first. To do so, you might use an asymetric algorithm, but then, you're reinventing TLS/DTLS ;)
Related
I'm using:
1. RSA/ECB/PKCS1Padding
2. AES/GCM/NoPadding
To encrypt my data in my Android (Java) application. At the documentation of SonarQube it states that:
The Advanced Encryption Standard (AES) encryption algorithm can be used with various modes. Galois/Counter Mode (GCM) with no padding should be preferred to the following combinations which are not secured:
Electronic Codebook (ECB) mode: Under a given key, any given
plaintext block always gets encrypted to the same ciphertext block.
Thus, it does not hide data patterns well. In some senses, it doesn't
provide serious message confidentiality, and it is not recommended
for use in cryptographic protocols at all.
Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is
susceptible to padding oracle attacks.
So, as it is recommended, I use AES/GCM/NoPadding as :
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
But, it still gives me the warning Make sure that encrypting data is safe here.
The same for:
Cipher c = Cipher.getInstance("RSA/ECB/PKCS1Padding");
Why does SonarQube throws that warning?
Aren't these uses safe any more?
AES in GCM mode is secured as a block cipher algorithm. But that doesn't guarantee that the code that encrypts data using AES (in GCM mode) is secured. Several things can go wrong leaving the code vulnerable to attacks. It is developers' responsibility to code it in the right way to get the desired level of security. Some examples where things can go wrong are:
The IV repeats for a given key
The key or the raw data are stored in String data type which keeps lingering in the heap
The secret key is stored in clear text in a property file that goes in the code repository
and so on.
Now, SonarQube cannot identify all these vulnerabilities and hence they've come up with a new concept called Hotspot which is described here as:
Unlike Vulnerabilities, Security Hotspots aren't necessarily issues that are open to attack. Instead, Security Hotspots highlight security-sensitive pieces of code that need to be manually reviewed. Upon review, you'll either find a Vulnerability that needs to be fixed or that there is no threat.
Hotspots have a separate life cycle which is explained in the link given above.
P.S. This answer explains how to encrypt a string in Java with AES in GCM mode in a secured way: https://stackoverflow.com/a/53015144/1235935
Seems like it's a general warning about encrypting any data. There shouldn't be an issue with "AES/GCM/NoPadding", as shown in their test code.
This is a Paw question. Is there a Paw encryption add-on that supports AES working in the commonly used modes and lengths?
I have a request that includes encrypted fields. These fields are AES encrypted. The key is 128 bits long. The encryption mode is CBC. The encryption is performed by the mobile app. The key is inside the mobile app.
At the moment, I capture the requests in Burp, Import them into Paw, and then I have the valid request.
I know the plaintext. I know the key. I know the algorithm. I know the Initialization Vector. There must be a better way.
I could not find anything on: https://paw.cloud/extensions/
There are two new DynamicValues that should allow you to do what you wish to do:
AES Decrypt
AES Encrypt
They are based on an npm port of the CryptoJS library and should expose most of the API for decryption/encryption in AES.
Here's a couple screenshot to show you what it looks like:
Since the DynamicValues are quite recent, there may be a few issues with them. Don't hesitate to report them.
AES256-GCM could be implemented in go as https://gist.github.com/cannium/c167a19030f2a3c6adbb5a5174bea3ff
However, Seal method of interface cipher.AEAD has signature:
Seal(dst, nonce, plaintext, additionalData []byte) []byte
So for very large files, one must read all file contents into memory, which is unacceptable.
A possible way is to implement Reader/Writer interfaces on Seal and Open, but shouldn't that be solved by those block cipher "modes" of AEAD? So I wonder if this is a design mistake of golang cipher lib, or I missed something important with GCM?
AEADs should not be used to encrypt large amounts of data in one go. The API is designed to discourage this.
Encrypting large amounts of data in a single operation means that a) either all the data has to be held in memory or b) the API has to operate in a streaming fashion, by returning unauthenticated plaintext.
Returning unauthenticated data is dangerous it's not
hard to find people on the internet suggesting things like gpg -d your_archive.tgz.gpg | tar xzbecause the gpg command also provides a streaming interface.
With constructions like AES-GCM it's, of course, very easy to
manipulate the plaintext at will if the application doesn't
authenticate it before processing. Even if the application is careful
not to "release" plaintext to the UI until the authenticity has been
established, a streaming design exposes more program attack surface.
By normalising large ciphertexts and thus streaming APIs, the next
protocol that comes along is more likely to use them without realising
the issues and thus the problem persists.
Preferably, plaintext inputs would be chunked into reasonably large
parts (say 16KiB) and encrypted separately. The chunks only need to be
large enough that the overhead from the additional authenticators is
negligible. With such a design, large messages can be incrementally
processed without having to deal with unauthenticated plaintext, and
AEAD APIs can be safer. (Not to mention that larger messages can be
processed since AES-GCM, for one, has a 64GiB limit for a single
plaintext.)
Some thought is needed to ensure that the chunks are in the correct
order, i.e. by counting nonces, that the first chunk should be first, i.e. by starting the nonce at zero, and that the last chunk should be
last, i.e. by appending an empty, terminator chunk with special
additional data. But that's not hard.
For an example, see the chunking used in miniLock.
Even with such a design it's still the case that an attacker can cause
the message to be detectably truncated. If you want to aim higher, an
all-or-nothing transform can be used, although that requires two
passes over the input and isn't always viable.
It's not a design mistake. It's just that the API is incomplete in that regard.
GCM is a streaming mode of operation and therefore able to handle encryption and decryption on demand without stopping the stream. It seems that you cannot reuse the same AEAD instance with the previous MAC state, so you cannot directly use this API for GCM encryption.
You could implement your own GCM on top of crypto.NewCTR and your own implementation of GHASH.
Somehow I don't get HMACs.
I once asked Why do I need HMACs when we do have public key signatures?, and I think I got this one. Easier to compute, and so on ...
But, what I do not get is why we need HMACs at all, respectively what kind of problem they are solving.
From my understanding, HMACs ...
provide a way to make sure the message has not been tampered,
are "secured" by a secret, but symmetric key.
Hence for calculating the HMAC (either initially or for verification) I do need to know the secret key.
Now, if I can exchange this key in a secret way without it being tampared, I could also exchange the message in the very same secret way without it being tampered, don't I?
Okay, now you could argue that you only need to exchange the key once, but you may have multiple messages. That's fine.
But if we now have a secret key that must be kept secret by all parties, we could also directly use symmetric encryption using the very same secret key to encrypt the message, couldn't we?
Of course, an HMAC shall provide a solution against tampering, but if I only have an encrypted message without the secret key and a reasonable encryption algorithm, I can not change that encrypted message in a way that a) decryption still works, and b) a meaningful decrypted message appears.
So what do I need an HMAC actually for?
Or - where is the point that I am missing?
You're assuming that it is impossible to tamper with an encrypted message without knowing the key used for encryption. This is not the case and a dangerous assumption to make. There are several things possible even if you only have access to the ciphertext:
Corruption of a suffix of the message: this can leak information about the content through error messages, timing and possibly other ways.
Corruption of ranges of the message for some modes (ECB, CFB and possibly others): same as above but the attacker has more ways to trigger the wanted behaviour.
Flipping of arbitrary bits in a single block (not knowing their initial value though) and corruption of the following block (CFB): If some bits are known to the attacker he can set them to the value he wants.
Flipping of arbitrary bits in the whole message for stream ciphers or stream cipher equivalent modes for block ciphers: This can avoid corruption altogether.
Thus it is very important to verify that no attacker tampered with the message before processing even a single byte of the decrypted content. Since there are again some pitfalls in doing this using ad-hoc verification or simple hashing there is a need for MACs of which HMAC is one example.
I did some research on the topic but could not find anything similar to my question. So I hope some of you great guys may help me out.
I want to use AES128 encryption (CFB-Mode) for the networking in my application between two individual clients. The data being exchanged consists only of textual strings of a specific structure, for example, the first bytes allways tell the recipient the kind of message they are receiving, so they can process them. With AES I want to ensure the confidentiality of the message, but now the question of "integrity" arises.
Normaly you would consider using a MAC. But isn't it guaranteed that nobody has altered the message, if the recipient is able to decrypt it correctly, i.e. that the message can be used correctly in his application because of the string's format? Wouldn't altering (even 1 bit) the encrypted message by a third party result in garbage during decryption?
Furthermore let's assume that the application is a multi-party peer-to-peer-game, where two of the players are communicating with each other on a private but AES-encrypted channel. Now the originator of the message is not playing fair and intentionally sending a fraudulent encrypted message to convey an impression that the message has been altered by a random third party (to force a player to quit). Now the recipient would have no chance to determine if the message has been altered or if the sender acts fraudulent, am I right? So Integrity would not be of much use in such a situation and could be neglected?
This may sound like an odd and out of world example. But it's something I recently encountered in a similar application and I am asking myself if there is a solution to the problem or if I got the basic Idea of AES encryption.
As you said, you may detect changes in the format of the plain text message after encryption. But at what level would it go wrong? Do you have something that is large and redundant enough to be tested? What are you going to do if the altered plain text results in some obscure exception somewhere down the line? With CFB (like most modes) an attacker can make sure that only the last part of the message is altered, for instance, and leave the first blocks intact.
And you are worried about cheats as well.
In my opinion, you are much better off using a MAC or HMAC algorithm, or a cipher mode that provides integrity/authentication on top of confidentiality (EAX or GCM for instance). If you are sure nobody else has the symmetric key, an authentication check (such as a MAC) will prove that the data has been signed by the correct key. So no, the user cannot claim that the data has been changed in transport if the authenticity checks succeed.
The next question becomes: can you trust that the symmetric key is only in possession of the other player? For this you might want to use some sort of PKI scheme (using assymetric keys) together with a key exchange mechanism such as DH. But that is for a later, if you decide to go that way.
This is a bit out of my depth, but...
Yes, modifying the encrypted bytes of an AES encrypted message should cause the decryption to fail (this has been my experience with the c# implementation). The client who decrypts will know the message is invalid. EDIT: apparently this is not the case. Looks like you'd need a CRC or hash to verify the message was successfully decrypted. The more serious problem is if the secret AES key is leaked (and in a peer-to-peer environment, the key has to be sent so the receiver can decrypt the message at all). Then a 3rd party can send messages as if they were a legitimate client, and they will be accepted as OK.
Integrity is much harder. I'm not entirely sure how robust you want things to be, but I suspect you want to use public key encryption. This allows you to include a hash of the message (like a signature or MAC) based on the private key to assert the message validity. The receiver uses the public key to verify the hash and thus the original message is OK. The main advantage of public key encryption over symmetric encryption like AES is you don't have to send the private key, only the public key. This makes it much harder to impersonate a client. SSL/TLS uses public key encryption.
In any case, once you have identified a client sending invalid messages, you're in the world of deciding to trust that client or not. That is, is the corruption due to malicious behaviour (what you're worried about)? Or a faulty client implementation (incompetence)? Or a faulty communications link?. And this is where encryption (or at least my knowledge of it) won't help you any more!
Additional regarding integrity:
If you assume no one else has access to your secret key, a CRC, hash, or HMAC would all suffice to ensure you detected changes. Simply take the body of your message, calculate the CRC, hash, whatever and append as a footer. If the hash doesn't match when you decrypt, the message has been altered.
The assumption that the secret key remains secret is quite reasonable. Especially if after some number of messages you generate new ones. SSH and WiFi's WPA both generate new keys periodically.
If you can't assume the secret key is secret, then you need to go to PKI to sign the message. With the AES key in a malicious 3rd party, they'll just generate whatever messages they want with the key.
There may be some mileage in including a sequence number in your message based on a RNG. If you use the same RNG and same seed for both parties, they should be able to predict what sequence number comes next. A 3rd party would need to intercept the original seed, and know how many messages have been sent to send valid but forged messages. (This assumes no messages can ever be lost or dropped.)