19,289 reputation
23291
bio website
location Brooklyn, NY
age 33
visits member for 3 years, 2 months
seen 16 secs 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).


Jun
5
comment In there any point in passphrase-protecting an SSH private key that is used by a service account?
@Kal - Sure. But I usually just run the cronjob as root. E.g., sudo crontab -e add a line where the command is 34 1 * * * /usr/bin/ssh -i /root/remote_host_cron_job_id_rsa user@remote_host and have the private key pair only root readable. This of course assumes I have root access. Yes this opens up an attack surface (if an attacker could replace the binary /usr/bin/ssh with something malicious, you get to run a binary as root when the cronjob next executes). It's better to set up another limited account client side that runs the cronjob and is the only user to read the key.
Jun
5
revised In there any point in passphrase-protecting an SSH private key that is used by a service account?
added 12 characters in body
Jun
5
answered In there any point in passphrase-protecting an SSH private key that is used by a service account?
Jun
1
revised Is a passphrase-protected SSH private key susceptible to a dictionary attack?
Added in necessary superscripts for exponents.
May
31
comment Are there any reasonable TrueCrypt forks?
@ignis the only concerns that I have seen that are shown to originate from legal council talk about the state of the license in 2.5 in Oct 2008. The two so-called trap paragraphs were significantly changed to specifically address those concerns. See comments to IstvanChung in other thread. Granted, as I pointed out above paragraph VI.2 seems questionable. But then its not a question of being able to fork truecrypt, its being able to legally use truecrypt.
May
31
comment Are there any reasonable TrueCrypt forks?
Again, legal discussion of an old version that was significantly changed is largely irrelevant. Similarly analysis of whether you are free to create a forked version (subject to some potentially annoying constraints) versus whether its sensible for a commercial entity to include it in their linux distribution (that they reserve the right to charge for) is a very different matter.
May
31
comment Are there any reasonable TrueCrypt forks?
@IstvanChung - Discussion of the TC License 2.5 is largely irrelevant as TC7 was released under 3.0. The two "trap" paragraphs Sec VI para 2, 3 are significantly altered, e.g., "NOTHING IN THIS LICENSE SHALL IMPLY OR BE CONSTRUED AS A PROMISE, ... NOT TO SUE FOR COPYRIGHT OR TRADEMARK INFRINGEMENT IF YOU DO NOT COMPLY WITH THE TERMS AND CONDITIONS OF THIS LICENSE. Missing that clause it does very much look like a trap. With that clause the trap seems much harder to legally defend. Similarly, paragraph 3 is qualified with "except as may be otherwise expressly provided in this License."
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