I wouldn't expect the difference to be too significant, once the connection is set up.
A breakdown of the overhead that TLS produces in general can be found here. The important bits are:
The total overhead to establish a new TLS session comes to about 6.5k bytes on average
The total overhead to resume an existing TLS session comes to about 330 bytes ...
SSL/TLS works well when the "server" is at known location (a fixed hostname) that can match the CN of the certificate it presents.
This doesn't work well for device on home networks (e.g. most IoT devices) because they tend to get IP addresses issued from RFC1918 blocks and do not have DNS entries. This means they can not be issued with certificates (well ...
If the service you use can tolerate some latency, routing the traffic of your device through the TOR network would make the destination address impossible to determine for your ISP, and the source address (home IP) impossible to determine for the ISP of the server your device is communicating with.
If you have only one device in your home, traffic patterns ...
Not really, your pretty much going to have to test and benchmark your specific situation. The following are likely to have a direct impact on performance.
What client/broker hardware are you using, does it have any hardware acceleration for crypto?
What is the size of the payload you are sending?
What is the connect/reconnect profile for your application?
For devices which are particularly sensitive, a good way to prevent someone from snooping the connection pattern is to generate spoof data, or intentionally skew the connection times (if data need not be uploaded as soon as it is generated).
Importantly, you would need to use static payload sizes, or generate plausibly sized payloads for the dummy data too.
One possible option is to use HTTPS and ship a real certificate on the device:
Since you control the access point you presumably control the DHCP server on the access point, so you can have it provide a DNS server address at the same time.
This DNS server can be on the AP and can resolve a fully qualified hostname to point to it's self.
You can then ...
What are the steps to the privacy leak described?
Basically there are three parts in getting the information described in the paper.
An interested party recording the outgoing traffic (2)
Said party being able to split the traffic streams (4.1)
Analyzing the different traffic streams
Identifying device (type) (4.2)
Analyzing device pattern (5)
While I like the use of TOR, you might not be able to configure every device to use it.
The simplest way would be to do something at the router, where all traffic, from all devices, enters and exits your house.
I would recommend a VPN router. This will encrypt all data leaving your home, so that no one, even you ISP, can see its destination. Data travels, ...
Making useful performance estimates is hard. It's likely that your application will require encryption for at least some of it's traffic, so there is unlikely to be any implementation cost to make security available for this subset of the traffic.
For an energy-constrained implementation, transmission is likely to be wireless. Even with a suitable radio ...
You would never run a TLS session tunnelled over MQTT. TLS connections expect a single bi-directional pipe over which to communicate, while it is possible to build this over MQTT, it is better suited to 1 to N* subscriber published data.
*(Where N can be 0 to infinity)
Just run MQTT over TLS as pretty much all MQTT broker already support this out of the ...
Generally, TLS is good for much more than x.509, but many implementations limit it to only x.509.
x.509 is a technique for a secure indirect trust. "A" trusts "B", if "B" has a certificate, which is signed by "C" and "C" is trusted by "A". That works also in real life; you trust someone you don't know, if a letter is presented signed by a person you trust. ...