101 reputation
bio website
visits member for 2 years, 7 months
seen 15 hours ago

comment How to explain Heartbleed without technical terms?
Arguably technical terms in this answer, that are not explained before being used: encryption, library, SSL, network traffic, server load, payload size,.. and that's about a quarter of the explanation in before I got bored. I think people here forget that a large part of the population doesn't know what a "browser" is.
comment How secure is Java's hashCode()?
@Adnan Certainly no crypto expert (and a 256bit key makes the chances of a collision minimal to say the least - works fine for git), but I agree with Ben here: If you don't use the object's hash/key/whatever for authorization, why not just use a simple counter? Guaranteed to be collision free, faster and simpler - also predictable but assuming a correct authentication method that's not harmful.
comment Why can we still crack snapchat photos in 12 lines of Ruby?
@theGreenCabbage Classic example of security of obscurity in any case. If you want the receiver to be able to see the picture, the receiver can make a copy of it. At least if you have full privileges on the phone which really isn't hard to achieve. Heck make the picture fullscreen (no idea about snapchat but I guess they allow that?) and just make a screenshot - no big difference in the result.
awarded  Announcer
comment Deleting a Java Object securely
@Thomas Pornin To nitpick a bit ;) Theoretically one can avoid the GC problems, the "solutions" are just somewhat.. complicated or need a compliant API. #1: ByteBuffer.allocateDirect(). #2: Use an unsafe object to allocate the necessary memory and craft your own char[] or string. #1 obviously only works with an API that would use CharBuffers (ugh) and #2 has more than enough problems (though I've wrote a small app once to win a bet). But in both situations you get memory that is not allocated on the GC heaps and therefore not copied around if you use a stop&copy GC.
awarded  Supporter
comment How should I compile program for fuzz testing?
You want to have a configuration in the test where you do not get saved by the enhanced debug checks like app verifier or the malloc_check stuff - but since every problem one of those two finds is (or should) be a bug that has to be fixed anyhow, wouldn't this only increase the chances to crash? You may crash at a different position (ie most likely earlier), but you'd still find the bug. The only problem I'd see is with undefined behavior that results in different code, but other than that I usually use the debug builds.