TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

PSA: Upgrade your LUKS key derivation function

275 点作者 YakBizzarro大约 2 年前

25 条评论

orlp大约 2 年前
&gt; His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced.<p>Sorry but there&#x27;s no world in which this password was bruteforced in 2023, even if they were using just SHA1 as their PBKDF. Even assuming just upper&#x2F;lowercase and 20 characters you are looking at 114 bits of entropy. To put this in perspective, if you could use the entire global bitcoin mining equipment (estimated at 350 million terahashes &#x2F; second) right now without modification to bruteforce this one password it would still take you 4 x 10^37 centuries. The author of the article failed to do this basic math.<p>The dude reused passwords, got keylogged, powned some other way, was coerced, had something unencrypted, or something else happened. But his password did not get bruteforced.
评论 #35614031 未加载
评论 #35612043 未加载
评论 #35612935 未加载
评论 #35612499 未加载
评论 #35615598 未加载
评论 #35612818 未加载
评论 #35615483 未加载
评论 #35617065 未加载
评论 #35612048 未加载
评论 #35616559 未加载
评论 #35621552 未加载
评论 #35612056 未加载
评论 #35616048 未加载
评论 #35615281 未加载
12345hn6789大约 2 年前
The creator of LUKS has a few words around this on Reddit. This appears to be a non-story unless you&#x27;re not practicing best proper password management<p>Clemens Fruhwirth here. I am the inventor of LUKS.<p>A random keyboard typable character gives you around 6 bits of entropy. 20 of those give you 120 bits of entropy. Even without a KDF, brute-forcing this key space is infeasible with today&#x27;s hardware. Even with PBKDF2, a 13-character password should be enough to keep your data secure for your lifetime.[1]<p>It is much more likely that there was some security failure in the linked case other than PBKDF2. That said, I support the upgrade to Argon2.<p>[1] In my thesis on LUKS, Chapter 5.3 Passwords from entropy weak sources anticipates the creation of specialized hardware for breaking PBKDF2. The &quot;13 characters should be enough&quot; advice is found on Page 86, Table 5.4, top left cell. It gives a 78-bit recommendation (=13 characters) in the worst-case scenario, which is Moore&#x27;s law continues to double the attacker speed every 2 years.<p>[0]<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;linux&#x2F;comments&#x2F;12q51ce&#x2F;psa_upgrade_your_luks_key_derivation_function&#x2F;jgpvsqc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;linux&#x2F;comments&#x2F;12q51ce&#x2F;psa_upgrade_...</a>
评论 #35616436 未加载
评论 #35616389 未加载
评论 #35615797 未加载
评论 #35616883 未加载
olabyne大约 2 年前
I&#x27;m french, and the source in french linked is not clear. The article is biased, the comments are saying it&#x27;s from 2020, and I am pretty sure the french cyber teams would not throw a bunch of GPU to solve a password for a small case like his.<p>Who knows if he used a non encrypted swap partition ? A leaked online account ? The guy complaining here doesn&#x27;t make it very clear if its encryption was broken either, he&#x27;s just over-interpreting the police reports by mentionnning some emails ?
评论 #35616042 未加载
jagrsw大约 2 年前
A naive question: Are KDFs meant to improve the security of systems or merely preserve it? I was under the impression that the purpose of KDFs is twofold:<p><pre><code> a) Preserve entropy of the password material (up to a limit - size of the input to the next stage) b) Derive a fixed-length output suitable for use as an input for the next cryptographic stage. </code></pre> If the password is, say, &#x27;abcd&#x27;, then it could be converted into an AES-128 key in the following ways:<p><pre><code> 1). Use &#x27;a&#x27;, &#x27;b&#x27;, &#x27;c&#x27;, &#x27;d&#x27; as the first four bytes of the AES-128 key (32 bits) in ASCII form, and then pad the rest with zeros or ones or use some other well-known pattern (based on convention). This method preserves entropy but is not computationally expensive. 2). Use a KDF like PBKDF2. </code></pre> On paper, PBKDF2 is a better option because an attacker would need to perform the PBKDF2 computation before each decryption attempt, which would be time-consuming. Therefore, as long as the KDF is implemented correctly, it should offer better protection than the first option.<p>However, if we&#x27;re talking about an attacker has the resources to brute-force a large number of generated passwords (based on real-world use or derived from hand-crafted or ML-derived criteria), they can precompute KDF outputs for each of those passwords and reuse them. This would make the second scenario (using PBKDF2) as easy or hard as the first one (using simple padding).<p>PS: Not a cryptographer, please don&#x27;t shoot!
评论 #35614789 未加载
评论 #35613278 未加载
Brian_K_White大约 2 年前
Could one seperate the kdf from the disk? Actually, not have any kdf?<p>Where the disk only has a fully secure huge random key, not generated by a kdf but supplied whole by usb or something.<p>Protecting that external component is a problem, but it&#x27;s a seperate problem, and having a copy of the drive, and everything else in your posession, and all the ram and gpus in aws doesn&#x27;t get you into that drive.<p>The external part doesn&#x27;t have to be a thumb drive right on your person. It could be stored anywhere on-line and&#x2F;or on paper, and you just know where it is and how to get it.<p>You might have to re-create some kind of thumb drive for conveient use, but you could also intentionally lose&#x2F;destroy it any time and not have it on your person during travel or sitting in a drawer at home. You would only recreate it when &amp; where you decided it was safe to.<p>I guess that&#x27;s what tpm aims to do. It&#x27;s physically on-board but not accessible, as long as you trust the chip maker.<p>Obviously I&#x27;ve spent about 5 entire minutes thinking about this. Please excuse.
评论 #35614104 未加载
评论 #35615233 未加载
ryan-c大约 2 年前
I would highly recommend setting the key derivation parameters to take as long as you can tolerate.<p>For example:<p><pre><code> --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4 --iter-time 60000 </code></pre> (4GiB memory cost - it&#x27;s specified in KiB, 4 threads (maximum), 60 seconds target time)<p>If you have an especially powerful machine, it seems to be able to use a significant fraction of total memory, so you can do something like this:<p><pre><code> $ time cryptsetup benchmark --pbkdf argon2id --pbkdf-memory 100663296 --pbkdf-parallel 4 --iter-time 150000 # Tests are approximate using memory only (no storage IO). argon2id 7 iterations, 100663296 memory, 4 parallel threads (CPUs) for 256-bit key (requested 150000 ms time) real 2m36.822s user 9m50.221s sys 0m18.921s </code></pre> Possibly an excellent trade-off for a desktop you rarely reboot.
评论 #35612669 未加载
评论 #35612521 未加载
runeks大约 2 年前
&gt; His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation [...]<p>It doesn&#x27;t really matter what kinds of characters your passphrase of 20 characters contains. What matters is how much entropy it contains, ie. whether it was generated randomly.<p>A random 20-character password containing just lower case English letters would still take more time to break than the age of the universe assuming one billion guesses per second.
评论 #35613353 未加载
xaduha大约 2 年前
&gt; Unfortunately it&#x27;s not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken.<p>Yes, it&#x27;s not practical to type that. So don&#x27;t, stop using passwords for this as a main way to unlock it. You can add a password as a backup key, but the main one shouldn&#x27;t include a keyboard. There are plenty of hardware options other than TPM that you can destroy if shit hits the fan.
评论 #35620612 未加载
评论 #35614522 未加载
TacticalCoder大约 2 年前
&gt; ... again and look for the PBKDF: line in each keyslot (pay attention only to the keyslots, ignore any references to pbkdf2 that come after the Digests: line). If the PBKDF is either &quot;pbkdf2&quot; or &quot;argon2i&quot; you should convert to argon2id<p>All good here then (Debian Bookworm default LUKS install):<p><pre><code> cryptsetup luksDump &#x2F;dev&#x2F;... | grep PBKDF PBKDF: argon2id</code></pre>
deafpolygon大约 2 年前
Interesting article;<p>I kind of want to ask a question here since I&#x27;m likely to run into my betters on this topic. How does macOS &#x2F; Windows 11 &#x2F; Linux stack up to each other in terms of full-disk encryption?<p>What&#x27;s the simplest approach to ensuring that my data isn&#x27;t as easily decrypted, and to protect myself? (I&#x27;m aware of other vectors like via Internet&#x2F;browsing, etc, but I&#x27;m concerned also about the physical security of my data).<p>Is macOS disk encryption pretty good all things considering? I see Windows 11 requires a compatible configuration to enable it for Home edition, or a Pro license. (Why?)<p>I&#x27;ve setup LUKS, created my keyphrases and all of that before on Fedora. But I&#x27;ll be honest, I don&#x27;t know how effective the defaults are and whether I&#x27;m doing the correct thing. I also worried about losing access to my data if the disk or LUKS volume became corrupted.<p>Any advice or tips for me?
评论 #35612511 未加载
评论 #35612846 未加载
评论 #35612593 未加载
ttyprintk大约 2 年前
Shufflecake has been posted recently:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33586503" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33586503</a><p><a href="https:&#x2F;&#x2F;shufflecake.net&#x2F;#news" rel="nofollow">https:&#x2F;&#x2F;shufflecake.net&#x2F;#news</a>
评论 #35614956 未加载
dathinab大约 2 年前
The problem with disk encryption on Linux isn&#x27;t that it doesn&#x27;t work.<p>It&#x27;s that while there is well working reliable core tooling, all the tooling around it, especially more higher level tooling is, well, not so grate and often incomplete.<p>This makes it a &quot;expert&quot; topic even through there is no fundamental need for it being such a topic.<p>At least for full disk encryption (encrypted `&#x2F;`), `systemd-homed` is it&#x27;s own, different, can of worms ;=) (and given that it add no benefit for a single user non-server laptop system with properly done full disk encryption I didn&#x27;t use it yet, so I can&#x27;t give feedback)
评论 #35620665 未加载
throwawaaarrgh大约 2 年前
AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don&#x27;t blindly follow blogs on a critical topic without more research
评论 #35614197 未加载
评论 #35614235 未加载
评论 #35622940 未加载
评论 #35614236 未加载
IAmLiterallyAB大约 2 年前
According to one of the experts on the panel of the Password Hashing Competition, Argon2 is actually weaker than bcrypt <a href="https:&#x2F;&#x2F;twitter.com&#x2F;TerahashCorp&#x2F;status&#x2F;1155129705034653698" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;TerahashCorp&#x2F;status&#x2F;1155129705034653698</a><p>I&#x27;m not an expert, but I&#x27;m really curious to hear more. It&#x27;s especially weird given I&#x27;ve heard nothing but good things about Argon2 otherwise.
评论 #35614413 未加载
评论 #35618534 未加载
评论 #35613759 未加载
thway15269037大约 2 年前
Totally random question that I was recently thinking about: can reuse of LUKS passphrases undermine security?<p>Yeah, yeah, I know, reusing passwords&#x2F;passphrases is bad and all, but consider only this use case: you have PC and have a laptop. Or you have a PC where you accidentally written your passphrase twice in two different slots (if that&#x27;s possible). Does that weaken protection? Or it would not help attacker in any way provided you kept passphrase safe?
评论 #35618893 未加载
Sesse__大约 2 年前
Seemingly you cannot convert live to LUKS2; you&#x27;ll need to unmount first. So that&#x27;s a bit sad, and would probably make distro conversion a more complex.<p>But I think maybe you can increase the number of PBKDF2 iterations? I heard at some point that the default in very old versions of cryptsetup, you&#x27;d always get 1000 iterations (which is very low), but nowadays, I think it&#x27;s based on timing the CPU you&#x27;re creating the volume on.
评论 #35615664 未加载
the-anarchist大约 2 年前
On a side note, regardless of whether and how big of an issue this is, from what I understand OpenZFS uses the same KDF: <a href="https:&#x2F;&#x2F;github.com&#x2F;openzfs&#x2F;zfs&#x2F;issues&#x2F;10764">https:&#x2F;&#x2F;github.com&#x2F;openzfs&#x2F;zfs&#x2F;issues&#x2F;10764</a><p>Gladly correct me in case I&#x27;m wrong.
jeroenhd大约 2 年前
&gt; Also, if you&#x27;re using an encrypted &#x2F;boot, stop now - very recent versions of grub2 support LUKS2, but they don&#x27;t support argon2id, and this will render your system unbootable.<p>That&#x27;s rather unfortunate. My knowledge of key derivation algorithms is a bit out of date, so can someone confirm that if an old volume is still using PKBDF2 headers you can still get some benefits upgrading to argon2i? Or are both of them equally useless at this point in time?<p>I&#x27;ve always wondered why the key algorithm depends on the speed of the CPU, this makes cheaper devices or handheld devices less secure for a second or two of extra boot time.
评论 #35612688 未加载
评论 #35612195 未加载
pshirshov大约 2 年前
There is the same (and ignored) problem in OpenZFS: <a href="https:&#x2F;&#x2F;github.com&#x2F;openzfs&#x2F;zfs&#x2F;issues&#x2F;14762">https:&#x2F;&#x2F;github.com&#x2F;openzfs&#x2F;zfs&#x2F;issues&#x2F;14762</a><p>Please vote there.
1827162大约 2 年前
Maybe using two layers of encryption, so if one fails, then we at least have another one to be bruteforced as a backup? Also two implementations, from different operating systems (!), e.g. why not store the data encrypted on a server running OpenBSD, which is then encrypted <i>again</i> using Linux LUKS. So then both the OpenBSD and Linux implementations would have to fail, in order for the government to be able to decrypt it. Of course, using different, long passphrases for each.
评论 #35619590 未加载
coppsilgold大约 2 年前
If he was under surveillance, all it takes is a microphone in the same room as his keyboard and it&#x27;s over: &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;shoyo&#x2F;acoustic-keylogger">https:&#x2F;&#x2F;github.com&#x2F;shoyo&#x2F;acoustic-keylogger</a>&gt;
naruhodo大约 2 年前
Notwithstanding the comments here refuting the vulnerability, this is an informative and potentially useful article. I learned some stuff.<p>FWIW, my fresh install of Fedora 38 uses argon2id as the KDF.
Crontab大约 2 年前
I think the mention that upgrading your distro doesn&#x27;t automatically enable a better KDF for LUKS is a good point.
brnt大约 2 年前
Am I the only one that chiefly uses FDE just so I only have to overwrite the LUKS header when I pass the drive on?
j0e1大约 2 年前
Obligatory xkcd: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;538&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;538&#x2F;</a>