| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Mar 2011 11:39:49 -0500 From: Charles Morris <cmorris@...odu.edu> To: Tim <tim-security@...tinelchicken.org> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: Python ssl handling could be better... > > Ok great, but by comparing MitM with sniffing, we're already assuming > the attacker has access to the traffic. Think about it. There aren't > any networks in common use today which in their physical > implementation make alteration of packets harder than observation of > packets. This is why the big-Os are the same. > Wrong. You can't just generalize "all existing /common/ networks match my idea of what is". You have to back up your statement with some argument. I already gave examples as to why reading isn't the same as writing, not by far. And you know, even if you weren't wrong, big O isn't the end-all of metrics. It's a useful metric, no doubt, but implying that "O(a) = O(b) => f(a) = f(b)" where f is a function that has security impacts is just foolish. A does not equal B. 5 does not equal 10. Reading does not equal writing. O(attack execution) does not imply f(attack execution).. e.g. Risk to attacker of being discovered. Monitor port does not equal ??mysterious nebulous MitM attack?? And you two are the ones complaining about snake oil :/ > I've had this conversation at many different times with different > people over the years. <snip> If you tell a lie enough times..... _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists