@vbabka I've tested these myself in OpenSUSE and Fedora. I'd try both #1 and #3 from previous. In Fedora after boot it was not otherwise working right off the bat.

... and I'm thinking of doing of my own command-line wallet.

My lessons learned from #ethprague was these are the key algorithms:

1. P256-K1 also known as the #bitcoin curve.
2. Keccak-256, as it was before it became SHA-3. AFAIK, they have just some padding incompatibility. This is the hash used in #ethereum.

I don’t see really any problem make them a bit more “stack compatible”. So maybe something to look at after I get my TPM2 public key patch set into the mainline.

So like when running bunch of servers, how to seal your keys properly, pretty basic stuff.

"It is a crime against humanity and human race overall if you leave your legacy to a machine."

That's it what I was trying to say.

Otherwise we might run into actual scenarios of pretty unpredictable consequences so now IMHO would be just best point in time to build some AI firewalls or something. This is also self-governance. What if one of your business partners turned into AI over night, after passing away night before? Entirely possible soon, like week before funeral, week after new AI me :-)

And someone might even want purposely want to leave the fortune after passing away through legit legal documents purposely. Legislation should really govern against this scenario proactively.

I'd hope to see #Google, #Microsoft and #Amazon put this forward. I.e. identify the biggest single risk with the AI correctly and just address the risk of inherited fortune. Not like "killing the whole industry of nonsense" ;-) #infosec

And without getting political or namesaying I can only say that whoever candidate is now they might consider also e.g. funder for their agenda. Money just talks, that never changes.

Governance for this loophole: put legistlation forward on inherited money and other fortune. That would be sort of reliable AI insurance for any society.

When thinking about #AI #threat in general, like in a #dystopian type of situation, I'd be more concerned on whether AI can inherit in #legal terms large amounts of cash or other #fortune.

I mean... it is simple really. The current ones just turn ******g off. But, if just by pure accident the tables were turned. That is undefined society model that probably does not have even a name yet

I'm always looking for an adventure, but not the AI slavery dystopian one... Be forewarned, I mean this have at least theoretical chances of actually realizing in a form or another. More like due than potential risk IMHO.

@ikkeT I've ended up not using LSP.

I think it has a wrong design. Microsoft could just as well do a single portable library with plugin interface for language provider modules. Then it could have way more sleek user experience.

Instead they made shaky IPC. It has all the same issues as using different terminal programs and lrzsz,

@monsieuricon This.

It is also hypocritical to criticize paywalls on platforms where you pay with personal data and by watching ads.

I did not know about ~/.config/nvim/after/plugin before reading this: https://fedoramagazine.org/configuring-neovim-on-fedora-as-an-ide-and-using-lazyvim/

At least in Fedora, also shared a access configuration needs to be defined in ~/.gnupg/scdaemon.conf:

# See for further information:
# https://github.com/OpenSC/OpenSC/wiki/GnuPG-and-OpenSC
card-timeout 5
disable-ccid
pcsc-shared

Otherwise, the earlier script needs to be run separately for each boot as a workaround. In OpenSUSE, I guess the defaults are different, given that everything just works without this extra configuration.

For gpg-agent I have the following entries in ~/.gnupg:

gpg-agent.conf
gpg-agent.conf.darwin
gpg-agent.conf.linux-gnu

In a new installation the correct configuration can be deployed as follows:

cp ~/.gnupg/gpg-agent.conf.$OSTYPE ~/.gnupg/gpg-agent.conf

#teardown and #bootstrap gpg-agent, pcscd to have a working configuration:

#!/usr/bin/env sh
# Copyright (c) Jarkko Sakkinen 2024
# Bootstrap gpg-agent and pcscd for Yubikey use.

GPG_AGENT_SOCKETS=(gpg-agent-ssh.socket
                   gpg-agent-browser.socket
                   gpg-agent-extra.socket
                   gpg-agent-ssh.socket
		   gpg-agent.socket)
systemctl --user disable --now "${GPG_AGENT_SOCKETS[@]}"
gpgconf --kill gpg-agent
sudo systemctl disable --now pcscd.socket

systemctl --user enable --now gpg-agent.socket gpg-agent-ssh.socket
sudo systemctl enable --now pcscd.socket

#yubikey

Why Curve25519 uses EdDSA for signing, and SECP-P256-R1 and SECP-P256-K1 use ECDSA?

It’s the scale. Curve25519 field has the size that fits within 255 bits, and two previous have the size that fits within 256 bits.

So from that follows:

• a new signature formalization is needed to reach similar or better results.
• given the smaller size it can only reach this goal by integrating tightly to the choices of the finite field parameters.

There is formal backing for this but pure common sense it is exactly like “if loose some, you must gain some” ;-)

#cryptography #note

I realized that I have something profound broken in my asymmetric TPM2 key series: TPM2 specific keys should only sign, not verify.

struct public_key, which is the central structure used for built-in, vendor and machine owner keys, should be able to verify the signature, even when the TPM chip is removed.

As a consequence, I will delete all the verification code from the key type(s) and set the supported_ops a KEYCTL_SUPPORTS_SIGN, instead of previous KEYCTL_SUPPORTS_SIGN | KEYCTL_SUPPORTS_VERIFY.

I’ll also rework tests to have two asymmetric keys: one for signing in the chip and other outside holding only the public key. That should also better verify that the feature is working correctly.

Would be nice if #systemd would release yearly #showcase image and ISO. Twice a year would be even better but a yearly "the state of systemd" would already do miracles!

In my opinion, a working design for kernel developers for this would be an image that would have the some recent release number, and easy way to build and deploy a test kernel.

Love the name of the #systemd's python-bindings: "pystemd"

Right. I should take my TPM2 signing code and merge it to struct public_key, use only TPM2_Sign and ditch TPM2_RSA_Decrypt.

Just hit me out of the void. Then e.g. builtin/secondary/machine keyrings, x.509 certiificates etc. is also in the finish line once this feature lands :-)

Three week clocked to the development so far so I think this is going in good phase.

I’ll start a new series (because it is not the exact same feature as before).

#linux #kernel #tpm