Search for 'sweet32 attack' . it's pretty much this technique - i think.
The CVE mentions that attack type atleast, and it has its own .info site to explain what it is...
The message type jeroenhd mentioned is useful here, as it generates a predictable response from the server, without having to sent actual email over it or authenticate against it. (so an external attacker can generate the needed encrypted traffic, with predictable / known plaintext). They dont know emails being sent, but they do know the response to EHLO. once the attack is acheived, they have a key, and can decrypt also other traffic sent by the service if you manage to capture it.
I'd say the thread-model or whatever is thus, someone who can sniff your email traffic and can speak to your smtp server. (if they can do the first, certainly they can do the second.)
its much harder to get to the email traffic outside of your network, but not impossible. (ISP for example can grab it easily.... - so in certain regions this might be a big risk - nasty governemnts etc..)
In your example, the attacker already has the session key for the TLS connection, so they don't need to run this attack to decrypt the traffic on that connection. And running the attack does not help them decrypt any other connections.
Sweet32 depended on the attacker being able to send an arbitrary amount of traffic over a connection where they did not control either of the endpoints, and with that connection also carrying the data they wanted to steal. That doesn't map at all to the proposed "infinite stream of EHLOs" attack.
cool! its odly satisfying to drag the colour side to side and watch the color resolution flicker from matching to mismatches in bands as it passes colours representable in the 3digit form
I went back and forth about the file system and disk stuff a fair bunch, to be honest. Most of it, as you say, was mostly due to wrestling the space constraints.
If one day I'll give in and take the shell out or go multi-stage, I will definitely look at that.
Maybe it's worth blogging about the journey; it's been a few weeks of merciless trade-offs to reach a usable API. It can make for a fun read (:
haha, well all the best! its a cool project. i am happy i can forgot about BIOS and went UEFI haha. remember so many tedious nights trying to get an mbr to load an elf file and init x64 mode in one go :'). uefi (edk2) is a blessing if you come from BIOS land (tho mybe less fun in a way!)
the BIOS will recognize block devices as being of certain type and present them to controllers.
if you do not put partition table, qemu AHCI controller will not recognize disk as bootable and u cant use SATA. with only the magic footer at the end of mbr, it will only work on IDE controller.
the BIOS will recognize block devices as being of certain type and present them to controllers.
What exactly do you mean by that? Device discovery proceeds from the root (usually PCIe bus, after CPU-specific init) to the leaves, not the other way around.
qemu AHCI controller
That's its problem then. This isn't a problem on real hardware.
free or not free is only an illusion. its a personal thing in the end which no one can give or take. hence, you will find disagreement on what behavior fits what banner of freedom or nonfreedom etc.
people will try to silence voices that disagree with them. cant they? no. will they try? yes.
dont worry about it and simply say what u have to say, trusting the universe it will arrive where it needs to, when it needs to.
i know its likely going to be an annoying question. but i cant find quick info on where my screenshots are sent and what kind of data is retained / how privacy etc. will work.
since this is device screenshots, kinda (not the same i get it) reminds of MS trying to grab the screens. It might be good to put some explicit text on such matters to reassure / inform people around it.
it was the first thing that came to my mind. (sorry, a bit biassed mind!)
also, kinda wondering why not photos too? what happens if the submitted picture is not a screenshot but a photo or a drawing? does it filter those out?
The message type jeroenhd mentioned is useful here, as it generates a predictable response from the server, without having to sent actual email over it or authenticate against it. (so an external attacker can generate the needed encrypted traffic, with predictable / known plaintext). They dont know emails being sent, but they do know the response to EHLO. once the attack is acheived, they have a key, and can decrypt also other traffic sent by the service if you manage to capture it.
I'd say the thread-model or whatever is thus, someone who can sniff your email traffic and can speak to your smtp server. (if they can do the first, certainly they can do the second.)
its much harder to get to the email traffic outside of your network, but not impossible. (ISP for example can grab it easily.... - so in certain regions this might be a big risk - nasty governemnts etc..)
reply