robertgraham

8 ms·

31.
by robertgraham 12y ago
Yup. Getting a private key using the extent simple scrypts is quite complicated, with lots of difficult steps. This is no barrier to teenage kids, who has lots of time on their hands that can play around until they get things right. As a de
32.
by robertgraham 12y ago
This isn't true. One of the things I'm famous for is creating "BlackICE" 15 years ago, an intrusion-detection technology that we shipped as a variety of products, such as a personal firewall, gigabit IDS, and inline prot
33.
by robertgraham 13y ago
I see what you mean; there are two things that most interest me. The first is "wow, did I just see them in action?". The second is that journalists are consulting the wrong "experts" in situations like this. They think &
34.
by robertgraham 13y ago
Actually, it's not just Huawei, it's pretty much all everything. Pretty much every router, telcom switch, storage system, etc. sold outside the United States comes with a support contract whereby the vendor's engineers can co
35.
by robertgraham 13y ago
There was no "tone" to the post. It's not pro or anti NSA. Something was in the news. I saw something related to that. So I reported it.
36.
by robertgraham 13y ago
That's my theory. Any monitoring of outgoing information would just see a typical attachment to a hotmail address.
37.
by robertgraham 13y ago
I can't reveal the exact SQL query because that's customer private information. However, it had both a subject and a timeframe that were peculiar. Googling the subject revealed news stories about it -- making it clear this was som
38.
by robertgraham 13y ago
Extremely common. It's the norm today that companies have firewall/VPN holes allowing support engineers from other companies to have access to their networks, to manage things as simple as the HVAC system, or things as complex as
39.
by robertgraham 13y ago
It was an internal system. We noticed with 'netstat' that it had a connection to an outside system. 'who' told us it was the account setup for Huawei remote support, and the IP address told us indeed that it was from a H
40.
by robertgraham 13y ago
No. It was a username/password assigned to Huawei tech support.
41.
by robertgraham 13y ago
I think that's FOSS compatible.
42.
by robertgraham 13y ago
I'm not using % on the result of rand(). I'm using the "Feistal network" construction that is at the heart of the data encryption standard, replacing binary operations like 'xor' with the "addition plus mo
43.
by robertgraham 13y ago
First of all, we avoid well-know "darknet" monitors that generate a lot of abuse reports. Second of all, we response personally to each abuse report and offer to include them in our "exclude" file so that we won't s
44.
by robertgraham 13y ago
It's 3 minutes per port. In the real world, you'll want to scan for many ports at a time. If scanning for all ports, it'd take 108 days at this rate.
45.
by robertgraham 13y ago
My scanner doesn't try to brute-force the logins. It's just grabbing the banner.
46.
by robertgraham 13y ago
"They" are me. What's up with this belief that anybody you haven't heard of is a member of some shadowy organization? I'm a well known security researcher, I give several presentations a year at cybersec conferences
47.
by robertgraham 14y ago
My point was to talk about the wrong problems. Networking is actually a "right" problem, and should be nearly embarrassingly parallel since two cores and process two unrelated packets at the same time. But, if you look at network stacks on
48.
by robertgraham 14y ago
My desktop is 6 hyperthreaded cores (12 "cores" total). It's a general principle of why mobile phone CPUs aren't putting a lot more cores in their devices, and why they didn't go the Atom route of hyperhreading: code on cellphones fail to
49.
by robertgraham 14y ago
Yea, some engineers created a ground-up rewrite of Snort called "Suricata" that was multi-threaded, and therefore faster than Snort, which is only single-threaded. Suricata then failed to show any benchmark where they exceeded Snort's speed
50.
by robertgraham 14y ago
They are NOT non-existent, they happen a lot in contention. That's why code fails to scale: as you add CPUs, contentions happen a lot more often, and the number of syscalls shoot through the roof.
51.
by robertgraham 14y ago
The entire point of the post was talk about "lock-free" algorithms where two cores can make forward progress without either having to wait or spin. What systems have mutexes that aren't built like futexes?
52.
by robertgraham 14y ago
When there is high-contention for a resource, it's better that one thread do it and access it contention-free, rather than make multiple threads content for it. Even so-called "lock-free" synchronization has locks, they are just very short
53.
by robertgraham 14y ago
(a) What part of "In the Linux pthread_mutex_t, when code stops and waits, it does a system call to return back to the kernel" do you not understand? That's how "futex" works: when it fails to get a lock, it must stop and wait, and therefor
54.
by robertgraham 14y ago
My blog post was quite clear that I'm talking about futexes, and then when it fails to get a lock that it goes into the kernel. Seriously, that's how everyone did it from Solaris to Windows before Linux "invented" the concept AND it's been