@janantos @duxsco Ah, right I always connect the whole to the distributed version! So it is taxonomy dependent how you argue about the topic. Thanks, I did not know nothing about David Chaum's past work. I will read that...

@janantos @duxsco Yep, I get a gut feeling that marketing department has mixed up blockchain and revocable ECDSA signature ;-)

@duxsco @janantos

Do want to slander our neighbor nation but I’m bit skeptical towards claim that Estonia had its first blockchain in 2007.

Bitcoin paper came out in 31st of October, 2008, so possible conclusions:

1. Bitcoin was not the first blockchain like within the metrics for such data structure that the paper defines.
2. KSI has some of the characteristics of those defined in the original Bitcoin paper but is not an “actual” blockchain.

Without better knowledge, bullet 2 is pretty good base assumption. Or who knows, perhaps Satoshi Nakamoto is an Estonian citizen or a group of citizens.

I want to my own so called wallet and looking at options of hardware incorporation:

1. TPM2: not feasible since does not handle P256K1 (only P256R1).
2. Hardware crypto wallets (from companies like Ledger): in my opinion worst inventions done during past 20 years. We need open and application agnostic keystore backends, not pollution like these.
3. FIDO2: Yubikey very compelling collection of crypto algorithms and ECC curves, including popular ones for blockchains.

So the choice is somewhat obvious based on this quick feasibility study: I want a FIDO2 wallet.

The next issue. I found this really nice FIDO2 wallet in C++: https://github.com/hoytech/defido2

My next question would be tho does anyone know is the choice of implementation language in this driven by “passion” or something actually preventing to do this using W3C API’s for FIDO2?

Does W3C API e.g. block some ECC curve types that my Yubikey might support?

#blockchain #wallet #w3c #fido2 #ethereum

@janantos @duxsco OK, so if my information is correct KSI uses the NIST curve, i.e. P256R1 and because of that ECDSA signatures. Bitcoin also uses ECDSA but with a different curve P256K1.

Meaning that even my in progress patch set can sign those when the private key is managed by a TPM chip [1]. Anyway good to know.

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t

@janantos @duxsco yep, well IMHO ID is always also a number ;-) Anyway, thanks a lot could not find it myself! Might become essential if the curves turn to be right :-)

Tomorrow I step through https://docs.oracle.com/en/learn/oci_nextcloud_ampere_a1/index.html

Stumped into a bug straight out right in the get-go ;-) It goes like this…

First, consider:

❯ cat pubkey.txt 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

Uploading this results “Invalid file type. SSH public key (.pub) files only” (screenshot #1).

Then, consider:

❯ mv pubkey.{txt,pub}
❯ cat pubkey.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

As can been seen from screenshot #2, the public key was successfully uploaded. For me this looks like as if validation was based on the filename extension o_O

A correct validation would ignore the file’s name and base validation on RFC 4716: The Secure Shell (SSH) Public Key File Format.

Stumped into a bug straight out right in the get-go ;-) It goes like this…

First, consider:

❯ cat pubkey.txt 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

Uploading this results “Invalid file type. SSH public key (.pub) files only” (screenshot #1).

Then, consider:

❯ mv pubkey.{txt,pub}
❯ cat pubkey.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

As can been seen from screenshot #2, the public key was successfully uploaded. For me this looks like as if validation was based on the filename extension o_O

A correct validation would ignore the file’s name and base validation on RFC 4716: The Secure Shell (SSH) Public Key File Format.

Since I switched from #Dropbox to #Storj, I’ve been almost solely using rclone.

Now I’ve started to feel that t it would be nice to have also an ownCloud instance and point out its storage to my #S3 bucket at Storj.

After looking through cloud options, I think got with ARM Ampere A1 VM: that #Oracle offers:

“Up to 4 instances of ARM Ampere A1 Compute with 3,000 OCPU hours and 18,000 GB hours per month”

Should scale a to my personal ownCloud with storage backend at Storj. The amount of OCPU hours nailed this really…

I also feel better when the server room that is "center piece of my digital life" is within homeland's borders ;-)

Right this is only people who live in Finland ;-) (nationality not required)

@Foxboron @duxsco
Morten just a summary

1. TPM's containing TCG algorithms for Ed curves are rare, or perhaps even non-existent.
2. Still, having `TCG_ECC_CURVE_ID` matters obviously because it hard requirement for having the implementation. 0.1% so much better than 0.0% odds, right?

Just paid 40 EUR annual bill for my Kapsi SSH account. It is the center piece of my digital life :-)

Kapsi has a IMAP inbox for my personal email and kernel.org mail (the same inbox is shared via RFC 5233 sub-addressing ), IRC screen (tmux), sometimes bots (tmux), exposing files via https URL’s (sometimes more feasible than e.g. dropbox shared links). It also provides for each user 50 GiB of backed up quota (with self-restore) and 500 GiB of space “in your own responsibility”.

Servers are hardened with quite reasonable standards and some of the people at Kapsi maintaining the backend actually know what they are doing when it comes to #infosec ;-)

It just continues to amaze me how dirt cheap this service is… and how awesome it is :-)

#Kapsi #Oulu #Finland

-

Resetting the commit history of pass

pushd  ~/.password-store
git checkout --orphan main2
git add .
git commit -a -s -m epoch
git branch -D main
git branch -M main
git push origin main -f    
git log -1
popd

Execution transcript:

~ main
❯ pushd  ~/.password-store
git checkout --orphan main2
git add .
git commit -a -s -m epoch
git branch -D main
git branch -M main
git push origin main -f
git log -1
popd

~/.password-store ~
Switched to a new branch 'main2'
[main2 (root-commit) a25d65b] epoch
# <snip>
Deleted branch main (was 0600cc7).

Enumerating objects: 76, done.
Counting objects: 100% (76/76), done.
Delta compression using up to 8 threads
Compressing objects: 100% (68/68), done.
Writing objects: 100% (76/76), 33.51 KiB | 11.17 MiB/s, done.
Total 76 (delta 0), reused 44 (delta 0), pack-reused 0
To kapsi.fi:git/password-store
 + 0600cc7...a25d65b main -> main (forced update)
commit a25d65b3ebcf87f45540bd54f209193fc5f1fef2 (HEAD -> main, origin/main, origin/HEAD)
Author: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Date:   Mon Jun 17 02:18:06 2024 +0300

    epoch

    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>

Meanwhile, while I'm on a #Ghidra bender this evening - I just found this neat tutorial on using Zynamics #BinDiff with Ghidra, via the #BinExport plugin:
https://www.0x90.se/reverse%20engineering/install-binexport-and-bindiff/

I'm planning to give this a go - while I had access to IDA+Bindiff, I used it a fair bit.

Edit - in case you missed it, BinDiff and BinExport are also now open-source:
BinDiff: https://github.com/google/bindiff
BinExport: https://github.com/google/binexport

Here’s the next steps for tpm2-cli.

Transient objects:

• tpm2-cli flush
  • TPM2_FlushContext
• tpm2-cli create
  • TPM2_Create
• tpm2-cli load
  1. ASN.1 decode.
  2. TPM2_Load
• tpm2-cli save
  1. TPM2_Import
  2. ASN.1 encode.

Persistent objects:

• tpm2-cli punch.
  • Inspired by fallocate(2) FALLOC_FL_PUNCH_HOLE.
• tpm2-cli persist
  • TPM2_EvictControl

So the basic gist here is that the command-line I/O goes always in ASN.1 format. Obviously other formats could be supported too but that is what I care myself ATM.

After that I’ll see how much the smoke test transcripts in my kernel patch set cover letter simplify:

https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

@Foxboron @duxsco that's a shame but at least it. can be now supported. i.e. could be worse ;-) K1 is not even the registry and getting to the registry is mandatory requirement for anyone to consider a new algorithm.

For kernel maintainers RSA + NIST does provide quite a good coverage for certificate keys, so as an opt-in feature, not required but can ease the workflow, it is level up even with just those two curves (and that was anyway my original take) :-)

@Foxboron @duxsco

OK so this is how these are:

• K1/R1: {256,384,521} bits finite field: ECDSA + SHA-{256,384,512}
• 25519: 255 bits finite field: EdDSA + SHA-512
• 448: 224 bits finite field: EdDSA + SHAKE256

They are all in the TCG Algorithm Registry so it is up to firmware updates to support it. TCG specifications have all assets to implement 448 signing (I just checked).

#factcheck

@Foxboron @duxsco ok so does it have shorter bit length than 255bits?
Less bits => new signing algorithm ;-)