Quick access to articles on this page:
more on the next page...
In one of my class the teacher advise against /dev/urandom.
I wondered why. I remembered reading some articles about random vs urandom and urandom being better, but that was years ago and my memory is not fresh. Wikipedia does advise against it, as does the manpage if you want to generate a long term key.
I also stumbled on one of Thomas Pornin's answer on the security SO also pointing to a blogpost from Thomas Hühn
tl;dr:
Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems.
An interesting 0day on paypal was discolsed by Yasser Ali.
We have found out that an Attacker can obtain the CSRF Auth which can be valid for ALL users, by intercepting the POST request from a page that provide an Auth Token before the Logging-in process, check this page for the magical CSRF Auth “https://www.paypal.com/eg/cgi-bin/webscr?cmd=_send-money”. At this point the attacker Can CSRF “almost” any request on behave of this user.
source
A CSRF attacks (Cross-Site Request Forgery) happens when you can send a link to someone (or embed it into an iframe on your website) and it makes the user do something on a particular website (like paypal) that he didn't intend to do. Or as the name of the attack says, it makes him send a request you forged from outside the website.
A CSRF token is used to cancel this attack. It's usually a random value that is send along the request and verified server side. This value is difficult to predict and thus you usually can't forge it along the request.
I wrote about Differential Power Analysis (DPA) but haven't said that there were way more efficient attacks (although that might be more costy to setup). Differential Fault Analysis is a kind of differential cryptanalysis: you analyse the difference between blocks of the internal state and try to extract a subkey or a key. Here we do a fault injection on the internal state of the smartcard during an encryption operation (usually with lasers (photons have the property of igniting a curant in a circuit), or by quickly changing the temperature).
The attack presented in http://eprint.iacr.org/2010/440.pdf and https://eprint.iacr.org/2003/010.pdf is targeting the last subkey.
We inject a fault on 1 byte of AES (in the picture we consider the internal state of AES to be a 4x4 matrix of bytes) at a particular spot (before the last round) and we see that at one point it creates a diagonal of errors. We can XOR the internal state without fault with the faulty one to display only the propagation of the fault.
Here, by doing an hypothesis on keys and seeing how the Addkey operation is modifying this difference we can compute the last subkey.
On AES-128, it is sufficient to know K10 to find the cipher key, but on AES-256, you must know K13 and K14
Although this is only my understanding of the DFA. It also seems to be easier to produce on RSA (and it was originally found by Shamir on RSA).
Google is introducing a new Captcha, instead of trying to read a distorted word and write it down (because robots have troubles reading distorted words) you will just have to click on one button. Google will analyze small cues that prove that you are not a robot (like the movement of the cursor before clicking on the button). Some of those cues will only happen when the mouse will hover the widget, as google is not in control of the entire document when used outside of google's domain.
see more info on wired
edit: more info on google blog as well
someone on hackernews:
It's definitely not only relying on cursor movements. A simple $('iframe').contents().find('.recaptcha-checkbox-checkmark').click() proved that I'm not a robot, without me touching the mouse.
It seems to rely heavily on your cookies as well.
I'm overwhelmed with interviews those last days. I just spent more than 8 hours on one (remote location, late trains, low battery, no keys... long story).
And like this is not enough, Hack Summit just started
Right now Ed Roman is introducing the hack.summit(). talking about a lot of good stuff and giving some book recommendations.
EDIT: Some notes on what he just said:
- pair coding (when you code and someone is watching, or the inverse)
- pomodoro technique (I'm already doing this, even made this)
- remove distractions (mail, phone...)
- pretend to talk and explain what you're doing/coding (close to my theory about writing down stuff to organize your thoughts, and pretend to write stuff on the table with your fingers to memorize it)
- iterate quickly, fail quickly and often.
- personalize your IDE
- use git, use the command line...
Now Scott Hanselman is talking but I have to go to the Champs Elysées drink some Glühwein at the Marché de noël some pardon me ;)
Now Tom Chi
I'm studying the internals of hash functions and MACs right now. One-way Compression Functions, Sponge functions, CBC-MAC and... the Merkle–Damgård construction. Trying to find a youtube video about it I run into... The Cryptography course of Dan Boneh I already took 3 years ago. I have a feeling I will forever return to that course during my career as a cryptographer.
The whole playlist is here on youtube and since his course is awesome I just watched again the whole part about MACs. And I thought I should post this explanation of the birthday paradox since as he says:
Everybody should see a proof of the birthday paradox at least once in their life
Something that always bugged me though is that he says the formula for the birthday is 1.2 sqrt(365) whereas it should be square root of 366 since there are indeed 366 different birthdays possible.
This morning I had a course on Return Oriented Programming given by Jonathan Salwan, a classmate of mine also famous inventor of RopGadget.
The slides are here.
A lot of interesting things there. Apparently it's still kind of impossible to completely protect your C code against that kind of attack. Even with all the ASLR, PIE, NX bit and other protections... There is also an awesome lecture about ROP on Coursera I linked to in the previous post here.
Basically, since you can't execute code in the stack, and since the addresses of libraries are randomized because of ASLR, you can find bits of codes ending with a return (called gadgets) and chain them since you control the stack (thus the saved EIPs). What I learned by doing was that it gets complicated if it's 64bits (since a lot of address will have a lot of 0x00 and you can't point to those doing a buffer overflow through a strcpy or something similar) and you won't get a lot of those gadgets if you have dynamically loaded libraries. Static libraries are loaded in the .text section (which is executable of course), so that's all good. Also a good way to store strings of data are in the .data section since it is untouched by the randomization contrarily to the stack.
A lot of researches is done on the subject and new tools like RopGadget are coming, using an old concept (but still actively researched): the SAT solvers. There seems to be a problem though, those SAT solvers yield a set of gadgets to be used for some action you want to accomplish with your shellcode, but you have to do the work of putting them in the right order.
This is what I took from that talk, you can question the guy if that interests you!
I've already talked about Coursera before, and how much I liked it.
The Cryptography course by Dan Boneh is amazing and I often come back to it when I need a reminder. For example, even today I rewatched his video on AES because I was studying Differential Fault Analysis on AES (which is changing bits of the state during one round of AES to leak information about the last round subkey).
So if I could give you another course recommendation, it would be Software Security by Michael Hicks. It looks ultra complete and the few videos I've watched (to complete the security course I'm taking at the University of Bordeaux by Emmanuel Fleury) are top notch.
