Bug#910249: Bumping up encryption to AES-256 by default
On 3/5/19 11:49 PM, Jeremy Bicha wrote: > On Tue, Mar 5, 2019 at 12:35 PM procmem wrote: >> I stand corrected its in your version since you cherry picked the patch. > Yes. Could you verify whether that version fixes your issue? > > Thanks, > Jeremy Bicha It does indeed. Thanks.
Bug#910249: Bumping up encryption to AES-256 by default
I stand corrected its in your version since you cherry picked the patch.
Bug#910249: Bumping up encryption to AES-256 by default
On 3/5/19 6:16 AM, Jeremy Bicha wrote: > I just uploaded libblockdev 2.20-7. Please check if it fixes your issue. > > If it does, would you be interested in filing the unblock bug to get > the fix in to Debian Buster? > > https://release.debian.org/buster/freeze_policy.html > > Thanks, > Jeremy Bicha Thanks a lot for following up on this. I had reported it upstream and am happy to see they fixed it. Looks like it made it into v 2.21 [0]. I would very much like to see it in Buster, but I'm clueless about how to do the unblock request despite reading about it now :( [0] https://github.com/storaged-project/libblockdev/blob/master/NEWS.rst
Bug#910249: Bumping up encryption to AES-256 by default
Jeremy Bicha: > On Wed, Oct 3, 2018 at 6:36 PM procmem wrote: >> Package: gnome-disk-utility >> Version: all >> Severity: serious >> >> Hi. I noticed Gnome Disks uses AES-128 by default instead of AES-256 >> like Debian does out of the box. Having 256 bit symmetric keys is good >> practice for long term security especially in a coming era of quantum >> computers. (Whether they materialize or not is deabatble but why not >> have a sufficient margin if it's easy enough?) It is also the >> recommended level by NIST. > > Please report this issue to the GNOME Disks developers: > https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues > > From what I can tell, Disks uses udisks2 which uses libblockdev. The > libblockdev default is 256 bits. > > https://github.com/storaged-project/libblockdev/blob/master/src/plugins/crypto.h#L39 > > So I'm not sure if the libblockdev default should be changed or if > that's something that GNOME Disks is supposed to handle itself. > > Thanks, > Jeremy Bicha > Thanks for pointing me to the code and upstream bugtracker :) I've opened a ticket on GNOME here: https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues/103 Feel free to close the ticket here because it's not related to you guys.
Bug#910249: Bumping up encryption to AES-256 by default
Package: gnome-disk-utility Version: all Severity: serious Hi. I noticed Gnome Disks uses AES-128 by default instead of AES-256 like Debian does out of the box. Having 256 bit symmetric keys is good practice for long term security especially in a coming era of quantum computers. (Whether they materialize or not is deabatble but why not have a sufficient margin if it's easy enough?) It is also the recommended level by NIST. This is verified by running: # cryptsetup luksDump --debug AES in XTS mode uses a keysize double its bit size (512 in this case) since with XTS the key is split in 2 so you actually get AES with 256-bit keys. A partition created by Gnome Disks shows it's only using MK size 256 instead of the expected 512. Please modify the source to pass 512 bit size to cryptsetup. For more details and original research by me see: https://www.whonix.org/wiki/Full_Disk_Encryption_and_Encrypted_Images#Protection_Against_Powerful_Adversaries
Bug#908917: corrections
Please disregard what I said in the background section of my original post. I will correct a few factual errors. Qunatum computing has nothing to do with using Argon2id. Argon2id promises up to a quadratic increase in mitgating GPUs vs the linear protection of PBKDF2-HMAC-SHA*. PBKDF2-HMAC-SHA* is not "totally useless" as stated earler, but rather less effective against GPU parallelization.
Bug#908917: (no subject)
Good to see you guys here. Debian packaging is in good hands. Thanks for explaining the roadmap and for the support on the dm-crypt ML. @Milan Broz Apologies. I am not an expert by any means and did not know all the implications of the command posted. So are you saying that using forced iterations for my purposes is OK? Is 50 a recommended value or just an example placeholder?
Bug#908917: cryptsetup: argon2id as default PBKDF setting for new installs - Buster+
Package: cryptsetup Version: 2:2.0.4-2 Severity: important Dear Maintainer, As part of my work on a downstream privacy distro I asked the cryptsetup team on how to transition current LUKS1 systems to use the improved argon2id algo for the PBKDF implementation when using LUKS2. Background: While quantum computing does not have any advantage in speeding up bruteforcing of PBKDF hashes they have a direct impact on passphrase length. Using a 20 word diceware passphrase will be needed for post-quantum passphase entropy of 256 bits. This is excessive and very difficult for most users to manage hence the importance of PBKDF for anti-bruteforcing. The current sha256 PBKDF used in LUKS1 is trivial to parallelize by adversaries who have large GPU computational power, making it a useless countermeasure and leading users to rely on passphrase lenth for only protection. *** It would be great if all newly installed systems running Buster and beyond used LUKS2 and argon2id out of the box instead of having users optionally opt for a safer configuration. The recommended config paramters by Milan Broz: # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 Original full reply: [0] https://www.saout.de/pipermail/dm-crypt/2018-September/005968.html Thanks
Bug#902237: Feature Request: Package plugin installer separately
W. Martin Borgert: > On 2018-06-23 17:21, procmem wrote: >> Package: gajim >> Version: all >> Severity: serious >> >> Please consider packaging the plugin installer separately (to make its >> install optional) as it prompts users to update and install additional >> code from untrusted sources which violates Debian's package security >> assumptions. >> >> (/usr/share/gajim/plugins/plugin_installer/) > > This is already done since some time. gajim-plugininstaller is > a separate package and not even suggested by the package gajim. > > Please try an up-to-date version of Gajim, e.g. 1.0.3-1 (Debian > unstable and testing) or 1.0.3-1~bpo9+1 (Debian stable with > official backports enabled). > Thanks. I just realized this after opening the report.
Bug#902237: Feature Request: Package plugin installer separately
Package: gajim Version: all Severity: serious Please consider packaging the plugin installer separately (to make its install optional) as it prompts users to update and install additional code from untrusted sources which violates Debian's package security assumptions. (/usr/share/gajim/plugins/plugin_installer/)
