Full Disk Encryption in Linux (Ubuntu / Mint) - secure?

Discussion in 'privacy technology' started by Forever, Jan 12, 2015.

  1. 142395

    142395 Guest

    If you use cascade encryption and one of its key was stolen, then weak hush could cause adversary to reverse salted password, thus he could break encryption. But if a key is stolen, sth is already wrong and it doesn't affect when you're using single encryption algorithm.
    [EDIT: I now saw TC document and it says when you use cascade, it makes double or triple sized key and then split it. So I think even with weak hush and when one of keys are stolen, still reversing salted password is impossible.]
    See this link if you don't trust what I said.
    https://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/
    Of course it's not the case in authentication, it's different story.
     
    Last edited by a moderator: Jan 13, 2015
  2. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
    So there is no need to encrypt manually over the terminal with SHA512 or Whirlpool when you set up a Linux machine?
     
  3. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
    Found this:

    "As hardware gets more powerful, password cracking in such an occasion becomes a lot more viable and SHA1, (Cryptsetup's default) which already we should be far away from (but aren't), looks even more deprecated."
     
  4. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    No problem :)

    In my opinion, using VPN services (especially mainstream ones like AirVPN or PrivateInternetAccess) attracts less attention than using Tor. Many people use VPN services to get around blocks on streaming (such as using Hulu or Pandora from outside the US) or to hide their torrenting. In many places, using VPNs is now too common to attract much attention. But Tor or I2P is far less common, and is still a useful marker for special attention.

    In places like China and Iran, even VPN use may be enough to attract untoward attention. And that may eventually be so in India and the UK, and who know where else, given the upset over the attacks in France.
     
  5. 142395

    142395 Guest

    That is about collision, and while it is serious matter for authentication program, don't matter in encryption program. If it matters as I temporary wrongly thought of in post #26, it's design flaw.
    If you have still doubt, I recommend to learn how LUKS use those hush. I always say only you can convince you. I haven't searched about it yet, only know Truecrypt's usage and it is actually PBKDF2. At least for TC, it doesn't matter or IOW it's matter of preference. Don't know how about LUKS yet.
     
  6. 142395

    142395 Guest

    Thanks, so I see major part of reason people use VPN + Tor is to evade Tor usage from mainly ISP, despite some additional tweak (e.g. ProxyCap) to make Tor compatible with certain VPN service/software.

    Even though those usage attracts attention still it won't be easy to actually de-anonymise them, just as discussed in NSA thread. I think SecurityKiss' post there was good summary of how it can be de-annonymised.

    Well, now I found these new threads.
    https://www.wilderssecurity.com/threads/will-using-vpn-get-me-flagged.372333/
    https://www.wilderssecurity.com/thre...up-as-a-potential-terrorist-indicator.372290/
    Maybe better to continue there?
     
  7. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
    so why does it not matter?
     
  8. 142395

    142395 Guest

    If you really want to understand it, you have to learn how the hush is used in the architecture.
    But for explanation sake, I'll give an easier example.
    We all know we can't use MD5 to check modification as an attacker can insert malicious code w/out changing its MD5 value.
    But does it mean you can't use MD5 to check file corruption? No, possibility that corrupted file happened to have exactly same MD5 value as the original is completely neglectable.
    So for hush, how and for what it is used matters.

    In short, weak hush only matters when header key is stolen (on TC case), but if the header key is stolen it's almost gameover. Contrary to this, in authentication hushed password theft shouldn't be gameover and this is why pass-the-hush attack is serious problem.
     
    Last edited by a moderator: Jan 14, 2015
  9. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
  10. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
    Moreover:

    Also, the statement that the underlaying hash function doesn't matter is completely false because there are security requirements that must be fulfilled by the hash function in order to the key derivation to be secure. Otherwise, there will be no need for cryptography and we can stick with 30 years old hash functions like MD4!!

    Anyway, in such security topics, one must carefully check any statement or information before endorsing it or using it. There are many out there who mislead people either on purpose or because they are ignorants of cryptography basics.
     
  11. 142395

    142395 Guest

    Are you aware you're writing about yourself?
    Explain me how weak hush can matter in Truecrypt. I bet you can't as I can tell you don't understand basics. Or ask any TRUE crypt expert, I'm sure about the answer.
    About your link, it's a shame such VPN provider too spread FUD. I said too, as I've seen such ignorant comments from seemingly techy people lots of times. BTW, I've been a reader of their only one source, Schneier's blog. And can't you see in that quoted link he clearly stated "it doesn't affect applications such as HMAC where collisions aren't important"?
    [EDIT: In case you don't know: TC's headerkey derivation is based on HMAC, though its purpose differ with usual HMAC case]

    Any decent crypt program shouldn't store hushed password anywhere else except for protected memory space. And in TC this hushed and salted password is headerkey itself (in XTS it's bit more complicated but I skip this as it's not essential). If attacker could steal the key, he can decrypt volume header and finally encrypted contents. So he doesn't need to reverse password by exploiting weak hash. Only possible scenario I can think of is that if you're using the same password in other way (same password for other encryption, or for online account) it will be worth reversing but I have to say that's the not a problem of crypt.
    OTOH, in authentication hushed password have to be stored somewhere, but theoretically even after it is stolen attacker shouldn't be able to login unless he could reverse password. In Windows there's known attack that attacker can login by this stolen hushed credential, this is well-known pass-the-hash attack. But it's exceptional case and usually attacker need to reverse original password, so weak hash really matters.

    Did you understand? I'm very sleepy but I replied you cuz you provoked me. Your last comment is needed? Say such thing at least after you truly understand things. If you are a guy who don't think by yourself but just rely on who said this, I don't want to talk with such authoritarian in any topic.
     
    Last edited by a moderator: Jan 15, 2015
  12. JRViejo

    JRViejo Super Moderator

    Joined:
    Jul 9, 2008
    Posts:
    73,137
    Location:
    U.S.A.
  13. Forever

    Forever Registered Member

    Joined:
    Nov 17, 2013
    Posts:
    54
    @142395 Sorry, I didn't mention that was a quote of the VeraCrypt developer. I don't know much about it so I decited to ask you guys :)

    Here is the link: http://sourceforge.net/p/veracrypt/discussion/general/thread/82add23d/?limit=25#dd8d/c382

    He does not say SHA1 is insecure in this contect, but hardware gets faster every year and SHA1 is only using 128 bit of key length. That is what he said. He said much more but you can visit the link and check yourself. I'd love to see your answer since I'm completely new at cryptografics.
     
  14. 142395

    142395 Guest

    Very sorry, I truly apologize to you for my offense! As JRViejo warned, I took that personally but it was completely wrong.:'(
    Also thanks JRViejo, I'll take more caution to interpret comments and step back before my post!

    Now I looked at the link, and what one of the Anonymous user wrote is true.
    I don't know from where he quoted it as he don't provide the link, but it's not matter and Mounir's reply about it is IMO pointless.
    Only reasonable interpretation I can think of is he's saying time to calculate SHA1 will be much faster so effectiveness of delaying brute force attack will reduce much IF you can't change iteration count. Otherwise it appears as if he's just defending what Veracrypt did and what he said. It'll be interesting to ask him that "Ok, I admit SHA1 is not yet danger. But then please explain how old weak broken, say, MD4 hash can matter except for delaying bruteforce w/out omitting any details?". I'm very curious about such not well-known attack vector if it really is as I've never heard of it. All I've seen is the same pattern, people just say it's danger w/out any details. Even a case I described (you use the same password for other) is hard unless the hash have serious preimage vuln which is bit different from collision. AFAIK MD5 still don't have that.

    OTOH, it's also true that there's no specific reason to use old, fast, short key length hash. When you can't change the number of iteration/repetition it's better to use long key length and more resource intensive hash algorithm to mitigate bruteforce attack, though it's much more important to use strong password.
     
  15. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    The Phase 1 Truecrypt audit exposed 11 potential vulnerabilities (3 of which were informational), one of which was the weak volume header key derivation algorithm, which was the most significant from my POV. I think this is what is being addressed here?

    However, as with most of these things for encryption of at-rest data, the answer is always: use a strong password, do not depend on strong KDF. There are a number of ways of generating and remembering strong passwords, typically which you choose is your preference. You do need to ensure randomness though, anything which is associated with you is vulnerable.
     
  16. 142395

    142395 Guest

    The paper of P1 audit says TC should let user can determine count of iteration as original 1000 or 2000 count is no more enough. It is about bruteforce and I fully agree, I can't understand why TC dev didn't it while made user can choose hush algorithm.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.