Hi I was looking for an example that will achieve multiple encryption in java , i.e encryption same piece of string or data multiple times so that i have layers of encryption.
The reason I want to achieve this is,As part of my university project I am trying to send some data from one machine to 3 hops and then destination. When sender sends it, it encrypts it with public key of destination ,encrypts again with 3rd hop's public key and so on, so when 1st hops recives it, it can only decrypt one layer and will find instrucitons to send to next hop, 2nd hop repeats the same process and passess it on to 3rd and same again untill it gets destination. This is so that none of the hops in the middle are able to see the data.
Thanks
There is nothing special about an encrypted file, it is just a stream of bytes. Encrypt it as you would any other file.
Related
I'm searching for some information about BLE and this question didn't find an answer. For the first connection between a master and a slave, it should be an exchange of keys, for encrypting. But for the next connection events, is it the same key or each connection event has its own key?
Thanks for your help!
BLE uses AES-CCM. Why don't you take a look at the Bluetooth Core specification Vol 6, Part E where this is described?
When encryption is started, the bonding key plus some random numbers supplied by both devices are used to derive a session key that AES-CCM will use. I'm not sure what you really are trying to figure out, but CCM uses a packet counter. This means every packet will be encrypted differently even if it contains the same data.
In case of SCTP multihoming, the client sends messages through one series of ip and receivers answer through another series of ip, after the primary ip is made down and up.
here I have configured 2 paths, primary path, and secondary path. Initially, all the messages will be transmitted in the primary path. Now im making primary interface down and all the messages will be transmitted in the secondary path.
Once I made the primary interface up, the first transaction is sent via primary path and answer is getting on the secondary path.
This happens only for the 1st transaction after interface made up. from the 2nd transaction, all the messages are going in the primary path and getting the answer back in the primary path itself.
Behaviour in case depends on a few factors, such as:
What SACK chunk is actually confirming. Whether it is actually the confirmation of the DATA that has been received via primary path, or confirmation for something that has been received previously.
Whether it is single SACK or SACK bundled with DATA chunks.
Whether it confirms DATA chunk received via one path or via two paths (e.g. first packet came via your secondary path and another one via primary). In first case according to RFC 4960 chapter 6.4 SACK should be sent via primary path, in the second case behaviour may vary:
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the same destination transport address from which it
received the DATA or control chunk to which it is replying. This
rule should also be followed if the endpoint is bundling DATA chunks
together with the reply chunk.
However, when acknowledging multiple DATA chunks received in packets
from different source addresses in a single SACK, the SACK chunk may
be transmitted to one of the destination transport addresses from
which the DATA or control chunks being acknowledged were received.
How strictly particular implementation follows RFC. RFC defined that SACK should be sent to the same destination transport address as source address of the received packet. Strictly speaking RFC does not define what source IP address should be used. E.g. if DATA chunk came in IP packet via IP1-IP2 path, according to RFC it is Okay to send SACK via IP3-IP1 ip path.
If I connect directly to another computer, I proof my IP. But what if I want to receive a message on paper which proofs someones IP?
For example, client contacts Google for an JSON web signature, prints it out on paper, gives the paper to me, and I can verify the signature of the message containing their IP, without ever connecting over to the client (or to Google) by TCP.
Is there a simpeler or better scheme possible?
If you use encryption, consider using HMAC. If not, then a simple hash or random number is fine for trivial use, as long as it is unique for a given period of time and then expires. Either way, you can send the generated value across both transports so they can be matched to each other. Preferably the server should generate the value to ensure its authenticity, eg:
"Hello TCP client, send me XXX and your IP over the other transport".
"Hello transport client, I see you sent me value XXX and IP YYY, I have a matching TCP client".
Also keep in mind that if your TCP client is behind a router, the other party is going to see your router's public IP, not your client's private IP behind the router. So your client will have to send the router's IP, and maybe also send its private IP as well. Depends on your actual needs.
I don't really see the need to validate the IP, though. Just dealing with the router situation, let alone trying to avoid IP spoofing, makes it almost not worth doing. Just having an authenticated token should be good enough.
Update: If that is not what you want, then you have to include the IP as part of the encryption/hash. The client takes some seed values (sometimes known as nonce values) and its IP and hashes them all together, then the result is given to the other party. That party uses the same seed/nonce values and the IP it wants to validate and hashes them together and sees if it comes up with the same result. If so, the IPs match.
I was wondering, is it possible to trace a packet that you send out of your own computer? The idea here would be to build something to protect your data. The packet sent out containing your password and other vital information is open to rerouting by a hacker. I want to know if it is possible (and if so, how I might go about approaching this) to trace the intermediate and/or final destinations of a certain packet, and then have them sent back to my computer for verification.
I would appreciate any help you guys could give on this matter.
There is no mechanism to do what you want. The packet itself might reach its "destination" just fine, only to be further re-directed elsewhere. Consider it like mailing an envelope -- whoever receives it is free to photocopy the contents a thousand times and send the copies to newspapers, tabloids, and telephone poles all over the world.
Same story with data -- once it leaves your computer, you have to trust the remote endpoint to not do anything harmful with it.
TLS and openPGP can go a long way to preventing third-parties from reading or modifying your data while it is in transit, but they cannot make sure the remote peer only handles your data with care.
No, not with ISO OSI, and there are other approaches to protect youre data
I am having an application where I have to send several small data per second through the network using UDP. The application needs to send the data in real-time (no waiting). I want to encrypt these data and ensure that what I am doing is as secure as possible.
Since I am using UDP, there is no way to use SSL/TLS, so I have to encrypt each packet alone since the protocol is connectionless/unreliable/unregulated.
Right now, I am using a 128-bit key derived from a passphrase from the user, and AES in CBC mode (PBE using AES-CBC). I decided to use a random salt with the passphrase to derive the 128-bit key (prevent dictionary attack on the passphrase), and of course use IVs (to prevent statistical analysis for packets).
However I am concerned about few things:
Each packet contains small amount of data (like a couple of integer values per packet) which will make the encrypted packets vulnerable to known-plaintext attacks (which will result in making it easier to crack the key). Also, since the encryption key is derived from a passphrase, this will make the key space way smaller (I know the salt will help, but I have to send the salt through the network once and anyone can get it). Given these two things, anyone can sniff and store the sent data, and try to crack the key. Although this process might take some time, once the key is cracked all the stored data will be decrypted, which will be a real problem for my application.
So my question is, what are the best practices for sending/encrypting continuous small data using a connectionless protocol (UDP)?
Is my way the best way to do it? ...flowed? ...Overkill?
Please note that I am not asking for a 100% secure solution, as there is no such thing.
You have several choices. You can use DTLS, which is a version of TLS adapated for datagrams. It is specified in an RFC and implemented in the openssl library. You can also use the IKE/IPsec protocol and use a UDP encapsulation of the IPsec portion. Usually IPsec is available at the OS level. You can also use OpenVPN, which looks to be a hybrid of TLS for key exchange and a proprietary UDP-based packet encryption protocol.
If your problem is that the data is too small, how about extending the data with random bytes? This will make the plaintext much harder to guess.
This question is a little old, but what about using a One Time Pad type approach? You could use a secure reliable transport mechanism (like HTTPS) to transmit the one time keys from the server to your client. There could be two sets of keys -- one for client to sever, and one for server to client. Each datagram would then include a sequence number (used to identify the one time key) and then the encrypted message. Because each key is used for only one datagram, you shouldn't be exposed to the small data problem. That said, I'm not an expert at this stuff, so definitely check this idea out before using it...
Use Ecdh key exchange (use a password to encrypt the client private key; left on the client) instead of a password. This is a very strong key.
Aes cbc does not help you; the messages are too short and you want to prevent replay attacks. Pad your 64 bit message (two integers) with a counter (starting with 0) 64 bits means 2^64 messages can be sent. Encrypt the block twice (aes ecb) and send e(k;m|count)|e(k;e(k;m|count)). Receiver only accepts monotonically increasing counts where the second block is the encryption of the first. These are 32 byte messages that fit fine in a udp packet.
if 2^64 messages is too small; see if your message could be smaller (3 byte integers means the counter can be 80 bits); or go back to step 1 (new private keys for at least one side) once you are close (say 2^64-2^32) to the limit.
You could always generate a fresh pair of IVs and send them alongside the packet.
These days a good streaming cipher is the way to go. ChaCha20 uses AES for a key stream. Block ciphers are the ones that need padding.
Still that's only part of the picture. Don't roll your own crypto. DTLS is probably a mature option. Also consider QUIC which is emerging now for general availability on the web.
Consider using ECIES Stateless Encryption https://cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme where you sending devices use the public key of the central system and an ephemeral key to generate a symmetric key pair, then a KDF, then AES-256-GCM. You end up with modest size packets which are stateless and complete. No need for an out-of-band key agreement protocol.
There are good examples on the internet, for example: https://github.com/insanum/ecies/blob/master/ecies_openssl.c
I am using such a system to deliver telemetry from mobile devices over an unsecure channel.