- cypherpunks - lists.cpunks.org

Re: GNU FSF: Richard Stallman Returns
by professor rat 04 Apr '21

04 Apr '21

Very Assange " ... Stallman came by to vacate his recently died mother's condo when a neighbor offered condolences in the lobby. The total shit handed her his business card, growled give me a call, sweetheart...' Objection - ' total shit ' assumes facts not in evidence. Like a letter calling for the deaths of 20 million ' Mud People " as published by the total Nazi cunt, John Young.

1 0

Re: grarpamps' fascist propaganda - Re: Coronavirus: Thread
by professor rat 04 Apr '21

04 Apr '21

James Arsehole Donald sounds like a very poorly recovering Marxist "... I argue that sexual behavior in small girls frequently sets in well before puberty, with the result that adult males in the general vicinity are apt to be punished for misconduct to which they scarcely contributed, because someone must be be punished, and women can do no wrong sexually. ...' Manifesto of the Communist Party Our bourgeois, not content with having wives and daughters of their proletarians at their disposal, not to speak of common prostitutes, take the greatest pleasure in seducing each other’s wives..."

1 0

Ron Paul: US 2nd Amendment In The Firing Line
by grarpamp 04 Apr '21

04 Apr '21

http://ronpaulinstitute.org/archives/featured-articles/2021/march/29/second… Authored by Ron Paul via The Ron Paul Institute for Peace & Prosperity, Gun control was already a Biden Administration priority before the recent shootings in Georgia, Colorado, and Virginia. In fact, the House of Representatives passed two gun-control bills weeks before the shootings. One of the House-passed bills expands background checks to include private sales, including those made at gun shows. Under this bill, someone who is not a licensed federal firearms dealer cannot sell a firearm without first relinquishing it to a federally-licensed dealer. The dealer must then conduct a background check on the prospective purchaser. The second bill allows the federal government to indefinitely delay a background check, thus indefinitely delaying a gun purchase. Other legislation introduced in Congress would create a national firearms registry, which would only facilitate gun confiscation. This same legislation would forbid anyone under 21 from owning a gun. The ban does not apply to the military, so it will not stop the majority of gun violence committed by 18-21 year-olds. The bill requires Americans to obtain a federal license before getting a firearm, but individuals cannot receive a license unless they undergo a psychological evaluation. The psychological evaluation mandate could lead to individuals losing their Second Amendment rights because they once suffered from depression. It could also cause people to lose their Second Amendment rights because someone told the police they may become violent. Police officers in 20 states and the District of Columbia already have the authority to take away an individual’s Second Amendment rights based on allegations and without giving the individual due process. These “Red Flag” laws are supported by politicians of both parties, including some who claim to be pro-gun rights. For example, former President Trump supported Red Flag laws. President Trump and Congressional Democrats were on the verge of reaching a “bipartisan” deal to expand Red Flag laws in the fall of 2019. Fortunately, the Democrat attempt to impeach the President ended all efforts at “bipartisan” deals to take away our rights. A psychological evaluation could also be used to deny an individual Second Amendment rights because they may engage in “domestic terrorism.” Among those likely to be considered as potential “domestic terrorists” are opponents of US foreign policy, mass surveillance, the income tax, the Federal Reserve, and – ironically – gun control. There is also legislation to reinstate the assault-weapons ban. Like the original ban, which was in effect from 1994-2004, the new legislation bans an arbitrary list of firearms and will do little to reduce gun violence. Criminals and psychotics are not going to be deterred by background checks and licensing requirements from obtaining a firearm. There will be a black market to service those who cannot obtain firearms by legal means. By discouraging law-abiding Americans from owning firearms, these laws leave millions of Americans defenseless against gun violence. There is a reason why most mass shootings occur in gun-free zones. If Congress is serious about protecting Americans from violence, it would repeal all federal gun control laws. A good place to start would be with the Brady background check law and the misnamed “Safe and Gun-Free Schools” law, which leaves children defenseless against mass shooters. Congress ending the unconstitutional and anti-liberty war on drugs would also greatly reduce gun violence. Gun control, like all attempts by government to control our lives, makes us less safe, and less free.

1 2

Earth Overshoot: Peak Phosphorus
by grarpamp 04 Apr '21

04 Apr '21

https://en.wikipedia.org/wiki/Earth_Overshoot_Day https://en.wikipedia.org/wiki/Peak_phosphorus https://en.wikipedia.org/wiki/Malthusianism

1 0

Details from 500 million Facebook users found on website for hackers | Facebook | The Guardian
by jim bell 04 Apr '21

04 Apr '21

https://www.theguardian.com/technology/2021/apr/03/500-million-facebook-use…

1 0

Feds say hackers are likely exploiting critical Fortinet VPN vulnerabilities – Ars Technica
by jim bell 04 Apr '21

04 Apr '21

https://arstechnica.com/gadgets/2021/04/feds-say-hackers-are-likely-exploit…

1 0

Pentagon linked to RMS, Jacob Appelbaum plots through Debian
by Debian Community News Team 03 Apr '21

03 Apr '21

https://debian.community/paul-tagliamonte-debian-usds-white-house-mob-ringl…

2 1

VICE: US ‘Broadband’ Joke, Guerilla MeshNets Fiber/RF Community P2P NOW!
by grarpamp 03 Apr '21

03 Apr '21

On 3/10/21, jim bell <jdb10987(a)yahoo.com> wrote: > VICE: The US Definition of ‘Broadband’ Is a Joke. > https://www.vice.com/en/article/k7av3n/the-us-definition-of-broadband-is-a-… “For years, we have seen billions in taxpayer dollars subsidize network deployments that are outdated as soon as they are complete, lacking in capacity and failing to replace inadequate broadband infrastructure,” Senator Michael Bennet wrote. “We need a new approach.” Yes the approach is called get the Govt and Corps out of the internet biz. Get with your neighbors and voluntarily lay your own guerilla fiber, peer to peer, owned parcel to owned parcel, across communities, farms, rivers, oceans, around the globe. Half the cost, twice the speed, encrypted, distributed uncensorable piecewise ownership and maintenance. You should have done it decades ago the moment meshnets became possible. Quit begging and paying at feet of GovCorp to keep putting you under their net servitude, spyveillance, and ongoing theft of your monthly $dollars into their political and profit coffers further propping up their powers over you stupid sheeple... wake up! Fiber is cheap, switches and RF and 1G/10G ports and even PON are all cheap cheap cheap distributed onetime investments paid for by as each neighbors node cuts the monthly GovCorp cord, shovels and beer and pizza are cheap, and opensource unix OS and routing protocols are free... less than one year of GovCorp monthly internet fee$... under $1000... gets you at least 10 years of 10Gig multihomed redundant link to two different neighbors... instant filesharing and voice video calls gaming and servers among all local peers, as the network grows to surpass traditional internet... go knock your neighbor's door and start building it, together. Ebay... Intel X520-DA2 10Gb 10Gbe 10 Gigabit Network Adapter NIC Dual Port E10G42BTDA $100 1 KM/1000M FTTH Indoor/Outdoor Single Mode 2-Core, Flat Aerial GPON Fiber $340 Board computer, tooling, boxes, etc ... It's that fucking cheap, one time, per node, wake up!!! The net slavery GovCorp is trapping you under does NOT end well. Escape it. Build it, Yourselves, Now!

1 3

GNU FSF: Richard Stallman Returns
by grarpamp 03 Apr '21

03 Apr '21

https://rms-support-letter.github.io/ https://github.com/rms-support-letter/rms-support-letter.github.io/ Petition for freespeech, against cancel culture...

7 10

Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248
by coderman 31 Mar '21

31 Mar '21

[Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248](http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs1… TL;DR: It's now easy to unlock your LUKS2 volume with a FIDO2 security token (e.g. YubiKey or Nitrokey FIDO2). And TPM2 unlocking is easy now too. Blogging is a lot of work, and a lot less fun than hacking. I mostly focus on the latter because of that, but from time to time I guess stuff is just too interesting to not be blogged about. Hence here, finally, another blog story about exciting new features in systemd. With the upcoming systemd v248 the [systemd-cryptsetup](https://www.freedesktop.org/software/systemd/man/system… component of systemd (which is responsible for assembling encrypted volumes during boot) gained direct support for unlocking encrypted storage with three types of security hardware: - Unlocking with FIDO2 security tokens (well, at least with those which implement the hmac-secret extension, most do). i.e. your YubiKeys (series 5 and above), or Nitrokey FIDO2 and such. - Unlocking with TPM2 security chips (pretty ubiquitous on non-budget PCs/laptops/…) - Unlocking with PKCS#11 security tokens, i.e. your smartcards and older YubiKeys (the ones that implement PIV). (Strictly speaking this was supported on older systemd already, but was a lot more "manual".) For completeness' sake, let's keep in mind that the component also allows unlocking with these more traditional mechanisms: - Unlocking interactively with a user-entered passphrase (i.e. the way most people probably already deploy it, supported since about forever) - Unlocking via key file on disk (optionally on removable media plugged in at boot), supported since forever. - Unlocking via a key acquired through trivial AF_UNIX/SOCK_STREAM socket IPC. (Also new in v248) - Unlocking via recovery keys. These are pretty much the same thing as a regular passphrase (and in fact can be entered wherever a passphrase is requested) — the main difference being that they are always generated by the computer, and thus have guaranteed high entropy, typically higher than user-chosen passphrases. They are generated in a way they are easy to type, in many cases even if the local key map is misconfigured. (Also new in v248) In this blog story, let's focus on the first three items, i.e. those that talk to specific types of hardware for implementing unlocking. To make working with security tokens and TPM2 easy, a new, small tool was added to the systemd tool set: [systemd-cryptenroll](https://www.freedesktop.org/software/systemd/man/syste…. It's only purpose is to make it easy to enroll your security token/chip of choice into an encrypted volume. It works with any LUKS2 volume, and embeds a tiny bit of meta-information into the LUKS2 header with parameters necessary for the unlock operation. Unlocking with FIDO2 So, let's see how this fits together in the FIDO2 case. Most likely this is what you want to use if you have one of these fancy FIDO2 tokens (which need to implement the hmac-secret extension, as mentioned). Let's say you already have your LUKS2 volume set up, and previously unlocked it with a simple passphrase. Plug in your token, and run: # systemd-cryptenroll --fido2-device = auto /dev/sda5 (Replace /dev/sda5 with the underlying block device of your volume). This will enroll the key as an additional way to unlock the volume, and embeds all necessary information for it in the LUKS2 volume header. Before we can unlock the volume with this at boot, we need to allow FIDO2 unlocking via [/etc/crypttab](https://www.freedesktop.org/software/systemd/man/crypttab.html). For that, find the right entry for your volume in that file, and edit it like so: myvolume /dev/sda5 - fido2-device=auto Replace myvolume and /dev/sda5 with the right volume name, and underlying device of course. Key here is the fido2-device=auto option you need to add to the fourth column in the file. It tells systemd-cryptsetup to use the FIDO2 metadata now embedded in the LUKS2 header, wait for the FIDO2 token to be plugged in at boot (utilizing systemd-udevd, …) and unlock the volume with it. And that's it already. Easy-peasy, no? Note that all of this doesn't modify the FIDO2 token itself in any way. Moreover you can enroll the same token in as many volumes as you like. Since all enrollment information is stored in the LUKS2 header (and not on the token) there are no bounds on any of this. (OK, well, admittedly, there's a cap on LUKS2 key slots per volume, i.e. you can't enroll more than a bunch of keys per volume.) Unlocking with PKCS#11 Let's now have a closer look how the same works with a PKCS#11 compatible security token or smartcard. For this to work, you need a device that can store an RSA key pair. I figure most security tokens/smartcards that implement PIV qualify. How you actually get the keys onto the device might differ though. Here's how you do this for any YubiKey that implements the PIV feature: # ykman piv reset # ykman piv generate-key -a RSA2048 9d pubkey.pem # ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem # rm pubkey.pem (This chain of commands erases what was stored in PIV feature of your token before, be careful!) For tokens/smartcards from other vendors a different series of commands might work. Once you have a key pair on it, you can enroll it with a LUKS2 volume like so: # systemd-cryptenroll --pkcs11-token-uri = auto /dev/sda5 Just like the same command's invocation in the FIDO2 case this enrolls the security token as an additional way to unlock the volume, any passphrases you already have enrolled remain enrolled. For the PKCS#11 case you need to edit your /etc/crypttab entry like this: myvolume /dev/sda5 - pkcs11-uri=auto If you have a security token that implements both PKCS#11 PIV and FIDO2 I'd probably enroll it as FIDO2 device, given it's the more contemporary, future-proof standard. Moreover, it requires no special preparation in order to get an RSA key onto the device: FIDO2 keys typically just work. Unlocking with TPM2 Most modern (non-budget) PC hardware (and other kind of hardware too) nowadays comes with a TPM2 security chip. In many ways a TPM2 chip is a smartcard that is soldered onto the mainboard of your system. Unlike your usual USB-connected security tokens you thus cannot remove them from your PC, which means they address quite a different security scenario: they aren't immediately comparable to a physical key you can take with you that unlocks some door, but they are a key you leave at the door, but that refuses to be turned by anyone but you. Even though this sounds a lot weaker than the FIDO2/PKCS#11 model TPM2 still bring benefits for securing your systems: because the cryptographic key material stored in TPM2 devices cannot be extracted (at least that's the theory), if you bind your hard disk encryption to it, it means attackers cannot just copy your disk and analyze it offline — they always need access to the TPM2 chip too to have a chance to acquire the necessary cryptographic keys. Thus, they can still steal your whole PC and analyze it, but they cannot just copy the disk without you noticing and analyze the copy. Moreover, you can bind the ability to unlock the harddisk to specific software versions: for example you could say that only your trusted Fedora Linux can unlock the device, but not any arbitrary OS some hacker might boot from a USB stick they plugged in. Thus, if you trust your OS vendor, you can entrust storage unlocking to the vendor's OS together with your TPM2 device, and thus can be reasonably sure intruders cannot decrypt your data unless they both hack your OS vendor and steal/break your TPM2 chip. Here's how you enroll your LUKS2 volume with your TPM2 chip: # systemd-cryptenroll --tpm2-device = auto --tpm2-pcrs = 7 /dev/sda5 This looks almost as straightforward as the two earlier sytemd-cryptenroll command lines — if it wasn't for the --tpm2-pcrs= part. With that option you can specify to which TPM2 PCRs you want to bind the enrollment. TPM2 PCRs are a set of (typically 24) hash values that every TPM2 equipped system at boot calculates from all the software that is invoked during the boot sequence, in a secure, unfakable way (this is called "measurement"). If you bind unlocking to a specific value of a specific PCR you thus require the system has to follow the same sequence of software at boot to re-acquire the disk encryption key. Sounds complex? Well, that's because it is. For now, let's see how we have to modify your /etc/crypttab to unlock via TPM2: myvolume /dev/sda5 - tpm2-device=auto This part is easy again: the tpm2-device= option is what tells systemd-cryptsetup to use the TPM2 metadata from the LUKS2 header and to wait for the TPM2 device to show up. Bonus: Recovery Key Enrollment FIDO2, PKCS#11 and TPM2 security tokens and chips pair well with recovery keys: since you don't need to type in your password everyday anymore it makes sense to get rid of it, and instead enroll a high-entropy recovery key you then print out or scan off screen and store a safe, physical location. i.e. forget about good ol' passphrase-based unlocking, go for FIDO2 plus recovery key instead! Here's how you do it: # systemd-cryptenroll --recovery-key /dev/sda5 This will generate a key, enroll it in the LUKS2 volume, show it to you on screen and generate a QR code you may scan off screen if you like. The key has highest entropy, and can be entered wherever you can enter a passphrase. Because of that you don't have to modify /etc/crypttab to make the recovery key work. Future There's still plenty room for further improvement in all of this. In particular for the TPM2 case: what the text above doesn't really mention is that binding your encrypted volume unlocking to specific software versions (i.e. kernel + initrd + OS versions) actually sucks hard: if you naively update your system to newer versions you might lose access to your TPM2 enrolled keys (which isn't terrible, after all you did enroll a recovery key — right? — which you then can use to regain access). To solve this some more integration with distributions would be necessary: whenever they upgrade the system they'd have to make sure to enroll the TPM2 again — with the PCR hashes matching the new version. And whenever they remove an old version of the system they need to remove the old TPM2 enrollment. Alternatively TPM2 also knows a concept of signed PCR hash values. In this mode the distro could just ship a set of PCR signatures which would unlock the TPM2 keys. (But quite frankly I don't really see the point: whether you drop in a signature file on each system update, or enroll a new set of PCR hashes in the LUKS2 header doesn't make much of a difference). Either way, to make TPM2 enrollment smooth some more integration work with your distribution's system update mechanisms need to happen. And yes, because of this OS updating complexity the example above — where I referenced your trusty Fedora Linux — doesn't actually work IRL (yet? hopefully…). Nothing updates the enrollment automatically after you initially enrolled it, hence after the first kernel/initrd update you have to manually re-enroll things again, and again, and again … after every update. The TPM2 could also be used for other kinds of key policies, we might look into adding later too. For example, Windows uses TPM2 stuff to allow short (4 digits or so) "PINs" for unlocking the harddisk, i.e. kind of a low-entropy password you type in. The reason this is reasonably safe is that in this case the PIN is passed to the TPM2 which enforces that not more than some limited amount of unlock attempts may be made within some time frame, and that after too many attempts the PIN is invalidated altogether. Thus making dictionary attacks harder (which would normally be easier given the short length of the PINs). Postscript (BTW: Yubico sent me two YubiKeys for testing and Nitrokey a Nitrokey FIDO2, thank you! — That's why you see all those references to YubiKey/Nitrokey devices in the text above: it's the hardware I had to test this with. That said, I also tested the FIDO2 stuff with a SoloKey I bought, where it also worked fine. And yes, you!, other vendors!, who might be reading this, please send me your security tokens for free, too, and I might test things with them as well. No promises though. And I am not going to give them back, if you do, sorry. ;-))

1 0