21,338 reputation
33699
bio website
location Brooklyn, NY
age 33
visits member for 3 years, 6 months
seen 49 mins ago
Good Morning how are you, I'm dr jimbob
I'm interested in things.
I'm not a real dr,
But I am a real jim bob.

Have a PhD in Experimental High-Energy Physics, but left academia in mid-2010 to program professionally.

Mostly program/script in python, django, and jquery these days doing mostly web apps.

Also have experience programming in C, C++, java, haskell, php, and (bash) shell more in the past.

Linux as primary OS since 1999, ubuntu user since 2005 (Hoary).


May
30
answered Are there any reasonable TrueCrypt forks?
May
30
comment Are there any reasonable TrueCrypt forks?
I do not believe your answer is accurate. TrueCrypt's license (taken from binary) explicitly gives you the right to modify and re-release as long as you (a) do not use the name TrueCrypt as the name of your product (e.g., can't call it TrueCrypt+), or (b) claim your modified version is from the TrueCrypt Foundation, (c) must display phrase "Based on TrueCrypt, freely available at truecrypt.org/";, (d) must provide source for free, and (e) don't alter license.
May
27
answered Does using the same encryption algorithm multiple times make a difference?
May
27
comment Are private git repositories safe?
+1 though disagree about the "but them" part of "nobody knows the answer but them". They may think everything is safe, have sensible policies, information safeguards, and do their best to keep private data private. But they may use some piece of exploitable software in their stack or employ some unethical individual who exploits flaws in internal policies. Take for example, Edward Snowden leaking private information out of the NSA that he shouldn't have had permission to access. I imagine the NSA has stricter policies around private information than github.
May
26
comment Does using the same encryption algorithm multiple times make a difference?
Granted there generally will be Meet in the middle attack that really only gives you 256 bits of security using O(2^128) bit space. And this isn't something brand new -- this is exactly what was used to strengthen DES (56-bit key) by making triple DES with 2^112 attack requiring 2^56 space.
May
26
comment Does using the same encryption algorithm multiple times make a difference?
Your figure of 2^129.58 (= 2^128 + 2^128 + 2^128) assumes you can break each key independently as if there's a checksum/MAC at each level (which would be a very dumb way of constructing multiple encryption). But if you do EncryptAES(K1, EncryptAES(K2, EncryptAES(K3, P))), then that's equivalent to using a 384-bit key as unless you simultaneously guess all 384-bits of all three keys at the same time there's no way to verify. DecryptAES(K, C) will not indicate that you guessed the key correctly or incorrectly.
May
26
awarded  Nice Answer
May
23
revised Cryptanalysis of encrypted data at rest
added 16 characters in body
May
23
revised Definitely safest password storage scheme?
deleted 100 characters in body
May
23
revised Expanding/Inverse Hash function
added 22 characters in body
May
23
answered Cryptanalysis of encrypted data at rest
May
23
awarded  Custodian
May
22
comment How to securely hash passwords?
Ok, caught my mistake. I think the 448 bits comes from 56*8, for the key used in eksblowfish not the output generated from bcrypt. Reading up more on bcrypt I see that its 192 bit encryption of OrpheanBeholderScryDoubt (in ECB mode - or was this changed to CTR at some point?) using 64 rounds of eksblowfish (which itself does 2^cost number of rounds).
May
22
comment How to securely hash passwords?
Doesn't bcrypt give a 448-bit output? From: schneier.com/paper-blowfish-fse.html Schneier does mention that simplifying bcrypt to be 8-round (versus 16), but otherwise says it can output keys of up to 448 bits. " It is probably safe to reduce the number of iterations from 16 to 8 without compromising security. The number of iterations required for security may be dependent on the length of the key. Note that with the current subkey generation procedure, an 8-iteration algorithm cannot accept a key longer than 192 bits."
May
22
awarded  Yearling
May
21
answered What benefit is there to adding a password to your SSH key?
May
21
revised Any reason I shouldn't be salting and hashing before putting through bCrypt?
added 570 characters in body
May
21
answered Any reason I shouldn't be salting and hashing before putting through bCrypt?
May
20
revised Does gmail's TOS allow Google to steal your emailed ideas?
added 873 characters in body
May
20
comment Serpent cipher technical details in-depth
Again comparing apples to oranges but finding a machine without AES-NI (Core 2 duo), I did time openssl enc -aes-256-ctr -K 13ca797952c0379e9b748ea8ceb8473d566cd012686fb7c0a225d83dabbecd80 -in file.txt -out file.enc -iv 01020304050607080910111213141516 took 6.4 seconds (real), 4 seconds (user) on 1 GB file of zeros, while time mcrypt file.txt -a serpent -m ctr -o hex -k 13ca797952c0379e9b748ea8ceb8473d566cd012686fb7c0a225d83dabbecd80 which took about 24.2 seconds. Granted mcrypt doesn't have AES -- it does have rijndael which I find quite comparable to serpent (23 seconds).