Silk Road forums
Discussion => Security => Topic started by: Quazee on July 14, 2013, 03:43 pm
-
Does anyone know what sized encryption the persistent volume in tails uses and if it is secure from most bruteforce attacks we would have to deal with here? Would I be safe if it was bruteforced by those nsa computers in utah? lol. After some reasearch I think LUKS in Ubuntu might use AES-256 but im not sure about tails. The only information I really found is that it uses LUKS, I stopped using truecrypt because I don't really trust it as much. I'm trying to make sure LUKS in tails is secure if anyone can help out?
-
Yeah, Tails uses AES-256. It's safe to use.
-
Yeah, Tails uses AES-256. It's safe to use.
Nice. you seem knowledgeable on the subject. Thanks for the reply!
-
"Yes, it is secure. Ubuntu uses AES-256 to encrypt the disk volume and has a cypher feedback to help protect it from frequency attacks and others attacks that target statically encrypted data.
As an algorithm, AES is secure and this has been proved by crypt-analysis testing. The weakness actually lies within the cypher and the software to pass it the keys. Specifically lies in the keystore (which is stored in the header of the volume), the keystore is secured by a passphrase. Passphrases are of course open to some attacks such as dictionary/brute force (if this was successful, it would decrypt the keystore). Using long "complex" non-word passwords would reduce the chance of this happening.
The only other possibility to decrypt is using recording devices or social engineering to determine your passphrase.
In short, your computer is reasonably safe unless you are subject to serious organised cyber crime or Government investigation!"
~ Source:***CLEARNETWARNING*** http://askubuntu.com/questions/97196/how-secure-is-an-encrypted-luks-filesystem
I don't mean to be "that guy" but you should startpage/duckduckgo it. You can find a lot of research but I suppose your encryption will only be as strong as your key.
I would personally consider LUKS encryption safe as long as you have a lengthy key with lots of variation.
-
LUKS does the key management (it's the Linux Unified Key Setup), dm-crypt performs the encryption and can use various ciphers, AES is the cipher. As long dm-crypt implements AES correctly, it should not be less safe than other programs that use AES-256.
On the other hand, a company named ElcomSoft released a program last year that steals encryption keys from RAM for TrueCrypt, PGP, and BitLocker encrypted containers, but not for LUKS/dm-crypt encrypted containers, so LUKS/dm-crypt is safer than those other programs, at least in that regard.
http://thenextweb.com/insider/2012/12/20/this-299-tool-is-reportedly-capable-of-cracking-bitlocker-pgp-and-truecrypt-disks-in-real-time/
-
LUKS does the key management (it's the Linux Unified Key Setup), dm-crypt performs the encryption and can use various ciphers, AES is the cipher. As long dm-crypt implements AES correctly, it should not be less safe than other programs that use AES-256.
On the other hand, a company named ElcomSoft released a program last year that steals encryption keys from RAM for TrueCrypt, PGP, and BitLocker encrypted containers, but not for LUKS/dm-crypt encrypted containers, so LUKS/dm-crypt is safer than those other programs, at least in that regard.
http://thenextweb.com/insider/2012/12/20/this-299-tool-is-reportedly-capable-of-cracking-bitlocker-pgp-and-truecrypt-disks-in-real-time/
All currently implemented systems are, to the best of my knowledge, vulnerable to this type of attack, to one degree or another. I believe that the original poster is placing too much emphasis on which cipher is used; any reasonably-modern cipher should be able to do the job. What is far more important, as you have pointed out, is the vulnerability of having the container's symmetric key snarfed from RAM. The other thing that is important is the quality of your passphrase. It really isn't going to matter what cipher is used, if you use a passphrase vulnerable to a dictionary attack, a too short one that can be brute-forced, or if you leave it on a sticky note by the monitor.
Nightcrawler
4096R/BBF7433B 2012-09-22 Nightcrawler <Nightcrawler@SR>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (MIT clearnet keyserver)
PGP Key: https://keys.indymedia.org/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia https: clearnet keyserver)
PGP Key: http://qtt2yl5jocgrk7nu.onion/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia .onion keyserver)
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090 (Silk Road Forums PGP Key Link)
PGP Key Fingerprint = 83F8 CAF8 7B73 C3C7 8D07 B66B AFC8 CE71 D9AF D2F0
-
LUKS does the key management (it's the Linux Unified Key Setup), dm-crypt performs the encryption and can use various ciphers, AES is the cipher. As long dm-crypt implements AES correctly, it should not be less safe than other programs that use AES-256.
On the other hand, a company named ElcomSoft released a program last year that steals encryption keys from RAM for TrueCrypt, PGP, and BitLocker encrypted containers, but not for LUKS/dm-crypt encrypted containers, so LUKS/dm-crypt is safer than those other programs, at least in that regard.
http://thenextweb.com/insider/2012/12/20/this-299-tool-is-reportedly-capable-of-cracking-bitlocker-pgp-and-truecrypt-disks-in-real-time/
All currently implemented systems are, to the best of my knowledge, vulnerable to this type of attack, to one degree or another. I believe that the original poster is placing too much emphasis on which cipher is used; any reasonably-modern cipher should be able to do the job. What is far more important, as you have pointed out, is the vulnerability of having the container's symmetric key snarfed from RAM. The other thing that is important is the quality of your passphrase. It really isn't going to matter what cipher is used, if you use a passphrase vulnerable to a dictionary attack, a too short one that can be brute-forced, or if you leave it on a sticky note by the monitor.
Nightcrawler
4096R/BBF7433B 2012-09-22 Nightcrawler <Nightcrawler@SR>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (MIT clearnet keyserver)
PGP Key: https://keys.indymedia.org/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia https: clearnet keyserver)
PGP Key: http://qtt2yl5jocgrk7nu.onion/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia .onion keyserver)
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090 (Silk Road Forums PGP Key Link)
PGP Key Fingerprint = 83F8 CAF8 7B73 C3C7 8D07 B66B AFC8 CE71 D9AF D2F0
LUKS does the key management (it's the Linux Unified Key Setup), dm-crypt performs the encryption and can use various ciphers, AES is the cipher. As long dm-crypt implements AES correctly, it should not be less safe than other programs that use AES-256.
On the other hand, a company named ElcomSoft released a program last year that steals encryption keys from RAM for TrueCrypt, PGP, and BitLocker encrypted containers, but not for LUKS/dm-crypt encrypted containers, so LUKS/dm-crypt is safer than those other programs, at least in that regard.
http://thenextweb.com/insider/2012/12/20/this-299-tool-is-reportedly-capable-of-cracking-bitlocker-pgp-and-truecrypt-disks-in-real-time/
All currently implemented systems are, to the best of my knowledge, vulnerable to this type of attack, to one degree or another. I believe that the original poster is placing too much emphasis on which cipher is used; any reasonably-modern cipher should be able to do the job. What is far more important, as you have pointed out, is the vulnerability of having the container's symmetric key snarfed from RAM. The other thing that is important is the quality of your passphrase. It really isn't going to matter what cipher is used, if you use a passphrase vulnerable to a dictionary attack, a too short one that can be brute-forced, or if you leave it on a sticky note by the monitor.
Nightcrawler
4096R/BBF7433B 2012-09-22 Nightcrawler <Nightcrawler@SR>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (MIT clearnet keyserver)
PGP Key: https://keys.indymedia.org/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia https: clearnet keyserver)
PGP Key: http://qtt2yl5jocgrk7nu.onion/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia .onion keyserver)
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090 (Silk Road Forums PGP Key Link)
PGP Key Fingerprint = 83F8 CAF8 7B73 C3C7 8D07 B66B AFC8 CE71 D9AF D2F0
You guys are awesome. <3 Yes, I have a very strong passphrase so I'm good with that.
I was really just curious what others thought about the encryption in Tails. I couldn't find any imformation on them altering it or anything.
so Tails wipes the ram after use so im good on that front
Hopefully I don't get raided and they keep it powered on. :p
-
Thanks Nightcrawler, that's good info.
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (MIT clearnet keyserver)
PGP Key: https://keys.indymedia.org/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia https: clearnet keyserver)
I'd just like to point out that nobody on this forum should be grabbing PGP keys from clearnet key servers unless they know how to properly configure their PGP client to work over Tor.
Key servers almost certainly log requests, so LE could create a forum account and post links like this to enumerate forum users. Or they could look for links like these posted on the forum and subpoena the key server operates for the requests. They couldn't prove you did anything illegal, but my philosophy is to never get my IP address on any lists in the first place, so I'm never on their radar.
-
Thanks Nightcrawler, that's good info.
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (MIT clearnet keyserver)
PGP Key: https://keys.indymedia.org/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia https: clearnet keyserver)
I'd just like to point out that nobody on this forum should be grabbing PGP keys from clearnet key servers unless they know how to properly configure their PGP client to work over Tor.
I guess I never thought of it because I never use client software to grab/look-up keys -- instead i used a web browser under Tor.
Key servers almost certainly log requests, so LE could create a forum account and post links like this to enumerate forum users. Or they could look for links like these posted on the forum and subpoena the key server operates for the requests. They couldn't prove you did anything illegal, but my philosophy is to never get my IP address on any lists in the first place, so I'm never on their radar.
You may have a point, but I fail to see where it benefits keyserver operators to log requests. I think that this is more of a theoretical vulnerability, as opposed to a practical one. Despite this, however, I will remove the clearnet links from my .sig.
Nightcrawler
4096R/BBF7433B 2012-09-22 Nightcrawler <Nightcrawler@SR>
PGP Key: http://qtt2yl5jocgrk7nu.onion/pks/lookup?op=get&search=0xB8F1D88EBBF7433B (IndyMedia .onion keyserver)
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090 (Silk Road Forums PGP Key Link)
PGP Key Fingerprint = 83F8 CAF8 7B73 C3C7 8D07 B66B AFC8 CE71 D9AF D2F0
-
Technically it's just as secure as TrueCrypt. And unlike TrueCrypt, which you can only download over an unsecure connection, Tails gets downloaded over a secure connection.
Downloading TrueCrypt over an unsecure connection means that an attacker could intercept the connection and give you their version of TrueCrypt with backdoor instead. Most people don't verify their TrueCrypt downloads.
-
I guess I never thought of it because I never use client software to grab/look-up keys -- instead i used a web browser under Tor.
My public key is on some key servers and I didn't upload it. The proof (to me) is that it is signed by a key that hasn't signed the key on my computer. So somebody was playing around with their PGP program, signed my key, and it uploaded it to a key server. That may have been the default action. So they leaked their IP address to the key server, along with their association to me and SR.
It's best for newbies not to fuck with key servers at all. Disable everything that has to do with them.
You may have a point, but I fail to see where it benefits keyserver operators to log requests. I think that this is more of a theoretical vulnerability, as opposed to a practical one.
Why? Key servers run on web servers and all web servers log IP addresses by default. If nothing else, the benefit is to detect malicious behavior, DDOS attacks and stuff like that. The side effect is being a target of subpoenas.