21,528 reputation
33699
bio website
location Brooklyn, NY
age 33
visits member for 3 years, 7 months
seen 22 hours 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
comment Are there any reasonable TrueCrypt forks?
Granted, you may not want to as their license kind of sucks in that it is quite restrictive compared to better licenses like BSD, MIT, or even GPL. I do agree that I would question including/distributing the TrueCrypt software in my linux distribution for potential legal reasons, especially if their is a commercial version of your software. But that's a separate issue. Note if you read through their legalese, the grounds to modify are equal to the grounds to use it unmodified. Granted, I'm not a lawyer, so don't take this as legal advice.
May
30
comment Are there any reasonable TrueCrypt forks?
@MichaelHampton - Again, I'm not a lawyer. I agree the license doesn't qualify OSI's "open source" or FSF's "free". But that's very different to "modifications and redistribution are not permitted". The clause you referred to about copyright infringement states "YOU MAY NOT USE, MODIFY ... EXCEPT AS EXPRESSLY PROVIDED IN THIS LICENSE". There is a huge section on the criteria to be able to modify it. I think if you followed their conditions you can distribute a modify version (credit truecrypt, don't use their name, distribute your source for free, keep their license, etc).
May
30
comment Are there any reasonable TrueCrypt forks?
@ignis - I agree, I'd be hesitant including TC in a linux distribution due to license issues (especially one with a commercial version) or one that you modified (and had to walk the careful line of giving TrueCrypt credit but not claiming it was made by TrueCrypt). The issue is nuanced and I tried to present it that way. Phillips highly upvoted answer just stated that you do not have the ability to modify and redistribute the source, where a large section of the license is dedicated to how you are permitted to do so, subject to some stipulation that make it not "free" in the OSI/FSF sense.
May
30
comment Are there any reasonable TrueCrypt forks?
@ignis - I tried repeatedly stating that IANAL. I understand that this doesn't count as FSF "free" or OSI-approved "open source" license. But that doesn't mean you do not have permission to view the source and modify it in compliance with the license. Taking non-free examples from gnu the JSON license isn't free as it states "the software shall be used for good, not evil" and say the old Scilab license didn't allow for commercial distribution of a modified version, etc.
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?