(I did find the commit fixing it, but it's huge, and I can't follow the change: https://github.com/openssl/openssl/commit/b1892d21f8f0435deb...
926 karma · joined April 2, 2012
(I did find the commit fixing it, but it's huge, and I can't follow the change: https://github.com/openssl/openssl/commit/b1892d21f8f0435deb...
One could argue that the CA/Browser forum has achieved some success with moving away from SHA-1. As a spectator, I don't understand why this process is not repeated for similar obsolete primitives or standards.
Obviously, this doesn't get you the benefit of being constantly drilled, but should provide some advantage. If you do care enough to get yourself a bigger advantage, maybe try to clear a few weeks before a round of job searching (if that's how you operate), then use those weeks for a few hours of practice each day.
I prob. missing something about [you're] "handing me your private keys to unlock that 1c output. Now if you ever released Transaction 1, I can spend both the outputs". What happens if you release transaction 1, then immediately release a transaction moving the funds away from that address? Seems like I have to be very vigilant and closely monitor the blockchain, fearing this will happen?
(also, both your plight and the efforts you put towards getting out of it sound very serious - best of luck to you)
- This sounds similar to the incast problem which occurs in datacenters, but this happens on consumer Internet - cool.
- After reading both this post and the TCP/NC paper, it seems to me like TCP/NC is unfair to vanilla TCP. If all TCP/NC does is send the same number of packets, but the packets are "more sophisticated" encodings of the original data, link utilization would be the same. So apparently, TCP/NC is more aggressive than vanilla TCP, and that's fine, but I think it should be acknowledged (haha). When they say stuff like "TCP doesn’t see the packet loss, and as a result there’s no need for the TCP senders to reduce their sending rates", it's a bit unclear what they mean - you can just as well modify the TCP stack to ignore the packet loss and not reduce the sending rate, without network coding.
- Why not use TCP termination? You could install a performance-enhancing proxy at the Sat gate, and make sure the link is always 100% utilized.
- "Let’s increase the queue memory" - I thought this should theoretically work. See for example http://yuba.stanford.edu/~nickm/papers/sigcomm2004.pdf. If folks familiar with the apnic effort are reading, I would love to know if they tried such measures and what happened.
- Could CoDel improve the situation here?
But I would love to know where I'm wrong about this.
A paper is currently making the rounds, would love to hear feedback:
https://www.dropbox.com/s/zy1gx1azfvvqm6i/NetSciComm%20versi...
Google search for "operation cleaver" brings up mainly mainstream news, and few infosec websites besides Cylance's own website - this could be an indication that the report is mainly marketing and hype. Discussion over at Reddit does seem to agree that there's a large marketing component to it, although there's good technical analysis alongside:
http://www.reddit.com/r/netsec/comments/2o1kdu/operation_cle...
A personal anecdote I just went through this week: a few years ago, I lost an interview with a company I really wanted to work for. Part of the reason I wanted to work there was that a lot of people I knew and respected worked there, and they seemed very happy when I visited for the interview. I was pretty down after that. This week one of the people who worked there reached out, and among other things we discussed, it appears he had a horrible time there, and there was no reason for me to feel down about not being accepted. Also, I spent this past summer as an intern at Google, and while I don't want to start the usual "is Google still a cool place to work at" fights here, I do feel comfortable writing that my own very subjective conclusion is that one can get stuck at an uninteresting role at Google, like in any other company.
Keep meditating, and keep being awesome.
But please bare in mind, I didn't really like my job as a software developer, and upon being cautioned about the drawbacks of academia by a tenure track professor I reached out to for advice, I simply shrugged and told him: "What's the worst thing that can happen - I'll end up being a software developer for 35 years instead of 40?" He immediately agreed that if that's the way I look at it, it probably makes sense to make the jump.
My contact info is in my profile, feel free to contact me if you want. And whatever you decide, good luck!
And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can't. Now, it seems likely you and I can hash out the details of an acceptable solution in this discussion (in fact, I think once you take the steps to make sure the random source isn't predictable, you're good, but even this is slightly crypto-related), but how would the average developer know this? How would he go from "don't write crypto code" to this? In my humble opinion, simply saying "don't write crypto code" isn't a solution, and there are good reasons why this hasn't worked so far.