search for: reencrypt

I'm not really a developer, but was considering if there is a key vulnerability in geli given that when you change a key there isn't a disk update. Consider the scenario where a new file system is created and populated with some files. At a later time the original key is changed because someone has gained access to the key and passphrase. A new key is generated and attached, but none of

Note that cryptsetup-reencrypt is a separate package on Fedora, but is already part of the appliance on Debian/Ubuntu. --- appliance/packagelist.in | 1 + daemon/luks.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ generator/actions.ml | 18 ++++++++++++++++++ gobject/Makefile.inc | 2 ++ src/MAX_PRO...

I am having a problem finding the best way to make a "before_save :encrypt_password" conditional. I have to at times update user model attributes but each time I do this the password is reencrypted because of the above. I need to differentiate between when the user is first logging in and the password does need to be encrypted, and when they are already logged in and the "before_save :encrypt_password" should not be called. eg if !signed_in? before_save :encrypt_password e...

I have existing systems with un-encrypted disks. I have tried unsuccessfully to encrypt them using LUKS. Has anyone out there been able to encrypt an existing system (after the fact, so to speak)? TIA -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.wells at leidos.com

...gt; Available from: http://soniq.net/gpgremail/ GPGRemail is a minimalistic mailinglist software, meant for small, private, mailinglists that require strong cryptography via the GNU Privacy Guard. It achieves it's integration with GPG by implementing a technique we call 'Transparent GPG Reencryption'. The basic idea is this: * gpg encrypt mail with mailinglist public key. * send to mailinglist. * gpgremail decrypts the mail with its private key. * gpgremail reencrypts the mail with each recipients private key, and delivers the mail. * decrypt mail with your own private key. T...

On 12/12/2017 08:41 AM, Wells, Roger K. wrote: > I have existing systems with un-encrypted disks. > I have tried unsuccessfully to encrypt them using LUKS. > Has anyone out there been able to encrypt an existing system (after the fact, so to speak)? You can do that with cryptsetup-reencrypt, but it needs to be able to make space for the ~2MB LUKS header ahead of the filesystem in the partition. That's a fairly risky operation -- shrinking the filesystem slightly and shifting it over. An alternative is LUKS with a detached header, but maintaining that relationship is an administrat...

...pm 43f682311a3dfae9cb6132fbfcd100b31003f24c21b8019c27f95b1c04e6f2bc cryptsetup-libs-1.7.4-3.el7_4.1.x86_64.rpm 8bf34548e14d4347b818e8ce09ab76f448bab1432a3516fcc1a8f87408160e20 cryptsetup-python-1.7.4-3.el7_4.1.x86_64.rpm 6438da0b9949137e449b462fba00aa210ab2a99ed6cfb977868388aac98c47a5 cryptsetup-reencrypt-1.7.4-3.el7_4.1.x86_64.rpm 3a5b5e16acde0e77961cb935165727b55f32b19c08425a64a960b6056047dc2a veritysetup-1.7.4-3.el7_4.1.x86_64.rpm Source: 580f96d2488c6a5050d0a9395542595a7eea8d761012c38a41250d161e4dfcfa cryptsetup-1.7.4-3.el7_4.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.o...

Hi all, authentication forwarding depends much on the environment it is used in, but generally on shared hosts it is considered insecure, as this documentation and common sense tell us: http://unixwiz.net/techtips/ssh-agent-forwarding.html Anyway, I have an auth forwarding security enhancement proposal. I hope I am not duplicating someone else's words/thoughts, please notify me if this is

...ine * New RSA keys will be generated with a public exponent of RSA_F4 == (2**16)+1 == 65537 instead of the previous value 35. * Passphrase-protected SSH protocol 2 private keys are now protected with AES-128 instead of 3DES. This applied to newly-generated keys as well as keys that are reencrypted (e.g. by changing their passphrase). Bugfixes: * Hold authentication debug messages until after successful authentication. Fixes a minor information leak of environment variables specified in authorized_keys if an attacker happens to know the public key in use. * When using Chroot...

...ine * New RSA keys will be generated with a public exponent of RSA_F4 == (2**16)+1 == 65537 instead of the previous value 35. * Passphrase-protected SSH protocol 2 private keys are now protected with AES-128 instead of 3DES. This applied to newly-generated keys as well as keys that are reencrypted (e.g. by changing their passphrase). Bugfixes: * Hold authentication debug messages until after successful authentication. Fixes a minor information leak of environment variables specified in authorized_keys if an attacker happens to know the public key in use. * When using Chroot...

I''ve configured our DMZ apache webserver to proxy connections from our roaming users into our internal puppet master running under passenger/apache. Everything is pretty much working but because I am using SSL between the proxy server and the puppet master, the master treats the connection as authenticated as the proxy. My current work around is to allow access to all catalog and

Looking for help regaining access to encrypted ZFS file systems that stopped accepting the encryption key. I have a file server with a setup as follows: Solaris 11 Express 1010.11/snv_151a 8 x 2-TB disks, each one divided into three equal size partitions, three raidz3 pools built from a "slice" across matching partitions: Disk 1 Disk 8 zpools +--+ +--+ |p1| .. |p1| <-

I''m looking for a way to run more than one puppetmaster on the same server under passenger. Most of the puppet CPU load is waiting for the catalogs to compile. This also seems to be mostly what takes large amounts of RAM. I have storedconfigs on. I want to be able to move the fileserver to a different pool of puppetmaster processes. Is there an easy way to tell the client, either in

...e * New RSA keys will be generated with a public exponent of RSA_F4 == (2**16)+1 == 65537 instead of the previous value 35. * Passphrase-protected SSH protocol 2 private keys are now protected with AES-128 instead of 3DES. This applied to freshly-generated keys as well as keys that are reencrypted (e.g. by changing their passphrase). Bugfixes: * When using ChrootDirectory, make sure we test for the existence of the user's shell inside the chroot and not outside (bz#1679) * Cache user and group name lookups in sftp-server using user_from_[ug]id(3) to improve performance on...