181 reputation
4
bio website blog.notdot.net
location Sydney, Australia
age 31
visits member for 2 years, 10 months
seen Jan 31 at 13:17

Software Engineer at Smart Sparrow, a startup in Sydney, Australia. Enthusiastic about software engineering and computer science, especially when it comes to interesting algorithms and approaches to solving difficult problems.


Jan
8
awarded  Commentator
Jan
5
comment Is AES encrypting a password with itself more secure than SHA1?
@skier88 Well, CBC-MAC is one approach you might try to use a cipher as you would a hash function, and as you can see it has flaws. I would analyze your construction, but you haven't actually specified it completely: what's the mode of operation? what's the IV, if applicable? What portion of the output to you use as the hash?
Jan
5
comment Is AES encrypting a password with itself more secure than SHA1?
@skier88 In this context, the 'tag' is the output of the CBC-MAC - see the Wikipedia article for more details. If it were a hashing function, it'd be the 'hash' instead of the 'tag'.
Jan
5
comment Is AES encrypting a password with itself more secure than SHA1?
@skier88 A MAC is a Message Authentication Code, and it's a common way to use a hash. Hashing passwords is slightly different, but similar considerations apply. My main point was to illustrate that building your own cryptosystems, even when seemingly safe, can have surprising undesired side-effects - so you should stick to primitives and systems that have been shown to be secure.
Jan
5
answered Is AES encrypting a password with itself more secure than SHA1?
Oct
25
comment Is a rand from /dev/urandom secure for a login key?
All this seems academic. The probability of randomly generating two identical 1024 bit messages is so absurdly low that it doesn't even bear consideration.
Sep
16
comment Cryptographic Security of Dynamically Generated, Non-Random Salts
It's not entirely the same. Salting with the username (a terrible practice, yes) would prevent economies of scale (or at least reduce them) but still permit precomputation. Using a fixed salt (another terrible practice) would prevent precomputation but still permit economies of scale.
Sep
16
comment Cryptographic Security of Dynamically Generated, Non-Random Salts
Good answer, but salts aren't just about economies of scale - they also prevent precomputation.
Aug
22
comment How would one fully protect himself against man in the middle-attacks?
The way you formulate this it's obviously impossible. You cannot protect against a man in the middle attack without out-of-band communication.
Aug
3
awarded  Teacher
Aug
3
answered Is the following authentication scheme secure?
Jun
28
comment Most secure password hash algorithm(s)?
@Core Why is adjusting manually not an option? Having security depend on server load seems like a bad idea.
Jun
27
comment Most secure password hash algorithm(s)?
@Core So users who change their password at peak hours will have less securely hashed passwords than those who change them during off-hours?
Jun
22
awarded  Autobiographer
Jun
22
awarded  Supporter
Jun
22
comment Are salted SHA-256/512 hashes still safe if the hashes and their salts are exposed?
Also, regarding bcrypt: Isn't the point that bcrypt is equally slow on a GPU (or at least has a much smaller speedup)? We can expect attackers to have GPUs, but most servers don't, so anything that reduces the attacker's advantage seems like a good idea.
Jun
22
comment Are salted SHA-256/512 hashes still safe if the hashes and their salts are exposed?
"Each additional charcter multiplies the time by 94, [...] 7 characters requires one day, 8 characters requires 7 years" - shouldn't 8 characters require 94 days?
Aug
8
answered Does prepending a salt to the password instead of inserting it in the middle decrease security?