SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,646
Rep:
Quote:
Originally Posted by CTM
The instructions do need to be reworked, but the default cipher now used by cryptsetup (aes-xts-plain64 with a 256-bit key) should be fine. Attacks on AES, even AES-128, are still only theoretical (and are a long way from being practical in the foreseeable future), and although it's now a matter of public record that state actors are trying to find a realistic cryptographic attack could be mounted against AES, there's no evidence that any of them have.
Unless you work in a US government department and are trying to keep TS material safe, worrying about AES key lengths is ill-considered: if someone wanted to decrypt your disk, there are much easier ways of doing it than attempting to mount a complex cryptographic attack against a FIPS 140-2-approved cipher (they could attempt to insert a backdoor into cryptsetup, for instance, or hit you until you tell them your passphrase).
Thanks for your answer. I have one question though: To archieve the same length compared to the examples in README_CRYPT.TXT I would have to specify "-s 256"? Or did I get that wrong?
And thanks for the reminder about the "brute wrench" method, funny indeed
Thanks for your answer. I have one question though: To archieve the same length compared to the examples in README_CRYPT.TXT I would have to specify "-s 256"? Or did I get that wrong?
README_CRYPT.TXT advises you to set up an AES-256-encrypted partition in CBC-ESSIV mode: to achieve that key strength in XTS mode, you'd need to specify a key length of 512 bits to cryptsetup ("-s 512"), because XTS mode requires two keys and cryptsetup derives them from the key it's given by splitting it in half.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,646
Rep:
Quote:
Originally Posted by CTM
README_CRYPT.TXT advises you to set up an AES-256-encrypted partition in CBC-ESSIV mode: to achieve that key strength in XTS mode, you'd need to specify a key length of 512 bits to cryptsetup ("-s 512"), because XTS mode requires two keys and cryptsetup derives them from the key it's given by splitting it in half.
Oh my, that's what I meant but didn't type. Thanks for clarification!
minimal-lxc.template within /usr/share/lxc/templates/lxc-slackware lists "logrotate", but not "dcron". Logrotate is mostly useless without dcron, so i suggest to add dcron or remove logrotate from minimal-lxc.template.
More precisely:
Code:
--- lxc-slackware.in.orig 2016-02-24 20:05:13.610963154 +0100
+++ lxc-slackware.in 2016-02-24 20:28:21.443387719 +0100
@@ -544,12 +544,14 @@
bin
bzip2
coreutils
+dcron
dhcpcd
dialog
diffutils
e2fsprogs
elvis
etc
+eudev
findutils
gawk
glibc-solibs
@@ -575,7 +577,6 @@
sysvinit-functions
sysvinit-scripts
tar
-udev
util-linux
wget
which
Code:
--- slack-desc.orig 2016-02-24 20:31:34.826430897 +0100
+++ slack-desc 2016-02-24 20:31:59.015063895 +0100
@@ -15,5 +15,5 @@
lxc: network space. It is similar to a chroot, but offers more isolation.
lxc:
lxc: Daniel Lezcano is the primary developer of lxc.
-lxc: Homepage: http://lxc.sourceforge.net/
+lxc: Homepage: https://linuxcontainers.org/
lxc:
It's on the radar, but I don't think it's a good option at this point. Quality-wise it might be fine on x86_64, but I'm a bit wary of the fact that comments on x86 support are not very confidence inspiring. My plan was to have another look at it with llvm 3.8, but that is most definitely out of scope at this point.
LLVM has a lot of extras available for it. A complete suite would be very intriguing. Libclc which provides OpenCL support to Mesa is part of that consortium. There are 13 projects in total.
Is there any particular reason why keybinder is explicitly built without Python bindings? I have just tried enabling them and they seem to compile and work fine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
