looking for some feedback - for new org page, is it preferable to have at github, gitlab, or repo.getmonero.org ?

surprisingly early feedback suggested github because it would have higher user engagement

Kind of have to agree with that

vtnerd_: Why not all three?

Lendri: wouldn't that split up discussion?

Hmm thats true

I am new to open source, so I didn't even think of that

yeah just I created on github - cifro-codes

maybe a coincidence but i recently got my ledger working with the 'pgp / ssh agent' app. it required me to install a python script (ledger_agent) ~ i can now login via ssh with my ledger / do pgp things

interesting org, vtnerd

What's an org ?

organization?

I thought about that one, but it didn't help make sense of the lines above :D

i stalk vtnerd on github and noticed a repo about unlocking a LUKS partition with hardware keys

yeah it works, and Im going to push out the code today

currently only with trezor, but I wouldn't be surprised if ledger works too

the hive mind in action, thanks!

*sorry, ledger won't work until I add the code, but Im not aware of any technical limitations

and plowsof[m] - yup - the difference is this code is designed to be statically built for linux initrd

so the only dependency is libusb - protobuf code is hand-rolled and uses the same interface that json serializer in monero-lws uses

Reminds me, I wanted to have a patch that'd read 32 bytes of a raw partition to xor with a key when loading a wallet.

yeah thats another thing Im trying to work on - a C++ interface for decrypting wallets, etc

because nearly every wallet should be decrypting metadata with these devices but arent doing it

Me being me, it'd have been a straight linux read(2) :D

and last I checked - all of the hardware wallets have shit privacy (except for monero related stuff)

But that sounds like a great addition, thanks.

anyway thats the point of the org - maybe come up with some ideas that turn $$$, to lessen my CCS requests OR at the very least have some projects that once stabilize and reviewed can be pulled into monero-project possibly

monero-lws is the big unknown because some have requested it go in monero-project, but if it can't Ill just re-assigned to this org

Well, another thing I had in my TODO (in fact, one of the first lines...) is a SSS scheme for monero-wallet-cli (really an extension of the "read 32 bytes off a partition" thing).

yeah that would be nice too

Never got round to it. IIRC it needs modular arithmetic and I'm not sure it can be done easily with EC.

SSS scheme?

Shamir's secret sharing. You split a secret in N parts so that M < N can be used to restore it.

Ah, ok

Kinda like multisig I guess...

Yeah, just wanted to say, can't possibly be any more complicated than multisig :)

I really should sign that code, but for the daring

its posted. it needs docs, and an official tarball I suppose

for those interested, instead of ECDH it does a ed25519 (deterministic) signature in the `macer://USER@HOST` namespace

since the USER@HOST is displayed on-screen, it helps with the scenario where one compromised machine can dump _other_ machine keys (the user must confirm display message)

a custom msg can also be displayed as well, which gets mixed into the signature output (verified by looking at trezor source)

moneromooo: I'd legitimately reuse multisig keygen for this, and then for recovery, just spawn n signing sessions yet leak the key share as you do it :p

It's potentially overkill regarding keygen as you have a trusted dealer yet act otherwise, and it'd be better for a proper key recovery function existed, yet the quickest hack to impl it is modifying the signing session code by duplicating it and renaming it :p It also just means we don't have two keygen share protocols laying around.

Though I will note, not to be an ass yet just to be honest, I actually already have this exact code available. That's not being an ass. The ass part is it's in Rust :p

So I'm not actually sure it's useful for you lol

A rust program for this might be welcome. It's self contained so oesn't reqiure maintainers to read/write/debug rust like it it were, say, part of the daemon being written in rust.

Though if it's a separate program it can also live as a separate repo and be linked.

But useful.

It's currently a library and I wrote private key recovery just for testing purposes. It'd just need to be composed into a C FFI OR hooked up to some JSON RPC server/file reader for whatever program you'd want in those regards.

`./monero-shamir generate --t 3 --n 5 new_keys` Print view key and address. "Please perform a test transaction before sending funds."

`./monero-shamir recover new_keys` Reads files in that directory to recover the key, printing the private spend key/view key/address.

Would that be good for you?

*new_keys in both of these examples are directories. It'd get populated with new_keys.1-5.json, new_keys.2-5.json... and then expect those JSON files to be there for recovery.

Well, I think it's a useful thing. But since I'm not contributing much at all nowadays, it's not for me to say yes/no to Rust stuff. But if people were to OK it, a standalone program would be the best way to do it.

I meant more specifically the API I was proposing :p

It sounds like this'll be mildly useful and honestly, it should only take half an hour to do if it's just those two commands.

I'd have got input on stdin but hey, it's personal preference really.

That's secondary :D

Fair enough :p I have my reasons against it but I'll get a proto and let you know

FWIW, I don't read/write/debug rust.

In case anyone is interested, I did successfully implement the above (albeit untested). It relies on work I have yet to disclose so I'll probably publish it in a week or so, when I publish the rest of it.