Cardano-cli signing a transaction without directly accessing the .skey file in plain text

But then you cannot call cardano-cli, but have to do what cardano-cli does yourself in your code.

I understand, I think that at the moment I am not qualified to do that. I am relatively new to developing in cardano. But I think the cardano-cli developers could bring a good security solution to this issue. I hope so.

Theoretically, you could have a bash script that accepts the python decrypted key as an argument, then in that script you’d something like ..-f <(echo $1)

There still remains @HeptaSean note that other processes might discover that file descriptor. I did a quick and simple test and always got a “Bad file descriptor” error when trying to access it in parallel.

This is just theoretical as I do not know all the security related implications of that approach.

2 Likes

No, because the only process that can read the data that’s written into the FIFO is the process that opens the FIFO by that same filename. In the meantime, whatever data flows through this “named pipe” only exists in the kernel’s active memory and the file system’s buffer cache.

Regarding an earlier comment, that’s why it’s secure as long as the same process that creates the FIFO is the one that opens it for reading:

In this case, the process effectively “locking” that FIFO (by being the first one to open it) is also the one who has the “security clearance” needed to read the private key. :sunglasses:

1 Like

I don’t think that’s completely correct:
screenshot-2022-06-26-22:46:30
I could later read the same FIFO with another process. Worse, if two processes read the FIFO, it seems to be random, which of the two get things written into it. 3 and 6 went to the second reader, 4 and 5 to the original one.

Excellent thank you very much. I’m doing a little research on this fifo (the truth is I didn’t know it). I still don’t understand why, but using mkfifo the information is accessible more than once, instead if I use mknod “named pipe” p , when reading the information from the pipe, it is automatically deleted, that is, a single reading, excellent! . I’m studying the difference and I still can’t find why it happens.

you can do the same test by starting the pipe with “mknod name p” , to see if this way it only takes the reading for you only once from a single place.

Behaves exactly the same on my machine:
screenshot-2022-06-26-22:56:58
1 and 2 were before opening the second reader. After opening the second one, they get distributed randomly (probably the next one being woken up by the kernel), 3 and 5 to the second reader, 4 and 6 to the original reader.

It’s very strange, I tried the same as you. It sends me the information from the pipe, to the last terminal where I focused on it before sending something through the pipe.

EDIT: I’m not sure, sometimes it does it like I say, sometimes it doesn’t, it’s a bit random.

thanks @HeptaSean @Ramiro for testing this idea further. Although I still believe native FIFO support might present a solution, it might only be secure between two process file descriptors on the opposite sides of a fork… with one process reading and the other one writing.

I was trying to recall how the Daedalus process does something similar & now I see it’s not with a named pipe at all… but a file descriptor (3) that’s inherited from the UI process which forks the node, which when closed will terminate cardano-node :thinking:

cardano-node run ... --shutdown-ipc 3 ...

Maybe some discussion on the above GitHub issue will reveal a better IPC method & if so I’ll post again here :sunglasses:

2 Likes

I’m not sure if it’s the solution, but it seems to me that the invalid key error working with fifo could be here.

When sending the content of the skey file, it has 352 characters, when it arrives through the fifo, it has 340 characters, I don’t know if the error will be here, but clearly it is not the same key if so many characters are missing.
When retrieving the info from the fifo, the quotes are lost…

{‘type’: ‘PaymentExtendedSigningKeyShelley_ed25519_bip32’…

{type: PaymentExtendedSigningKeyShelley_ed25519_bip32…

These quotes would be lost when processed by the shellnot when going through the FIFO: the difference in data size is probably the number of quote characters you have in the data, perhaps adjusted by some changes in white space. Have a close look at exactly how you are “retrieving the info from the fifo”, to double-check the code that you are using: Quotes - Greg's Wiki

… but remember fixing this wouldn’t get around the problem documented here & on GitHub because a “named pipe” filename still wouldn’t be read at all by cardano-cli.

1 Like

If you’re using python, I think I suggested it elsewhere, but why re-invent the wheel - you do have python/go/multiplatform libs. Using wrapper to CLIs are not the best solutions unless you’re using shell scripts

2 Likes

You are so right.

Unfortunately, the “official” Cardano integration documentation https://developers.cardano.org/docs/integrate-cardano/listening-for-payments-cli#query-utxo thinks it’s a good idea. …

It is one of the few places that is supposed to be managed by community, so hopefully some of us find the time to add updates there

3 Likes

Is this library official? The truth is that to use them on mainnet if they are not official libraries, I am a little scared to use them.

Those are three different libraries by widely trusted projects.

No, not official, but “official” would also have to be defined first. Are only things by IOG official? Or only things by one of the three founding entities – IOG, Emurgo, or Cardano Foundation (where the latter is not really doing development)? Or things funded by Catalyst, although that’s just the financing?

The last one – https://github.com/dcSpark/cardano-multiplatform-lib – seems to be a fork of https://github.com/Emurgo/cardano-serialization-lib, which is by one of the founding entities, but I guess the dcSpark fork is better. A lot of developers have gone from Emurgo to dcSpark.

1 Like

I understand what you mean by officer. For what you say, I consider the ones you show official. I’ll look at them in detail later, but I wonder, can they be used with python?

No, the cardano-multiplatform-lib/cardano-serialization-lib is Rust compiled to different Javascript/Typescript platforms.

The Python library ­– https://github.com/cffls/pycardano – is, unfortunately, not official, but by a single developer, whom I, personally, do not know much about, except that he got a quite large fund in the latest Catalyst round for developing this further: https://cardano.ideascale.com/c/idea/398206
As said, that does not necessarily mean much, other than that there are a few people who have looked into his work in more or less detail and found it very worthwhile.

Cardano is supposed to be an ecosystem and there are a lot of developers, companies, projects working in it that have nothing like an official blessing, but are often better than the (semi-)official ones. It is a valid policy to only use a certain kind of “official”, but it will also lead to missing very interesting stuff. Perhaps, we need some kind of more formalised review than: “Well, a lot of us think, it’s okay.”

1 Like

Thank you very much for your information. I was seeing several developments and the truth for my own peace of mind, I have to analyze all the code carefully to understand what to do and see if there is not an information leak or something evil. Because I will work on mainnet and it can be dangerous. This takes a lot of time and effort, for this reason, I got into the idea of ​​developing something of my own. I don’t like to reinvent the wheel, but if there isn’t something “official”, at the moment it’s what leaves me calmer. In the same way, I will investigate in detail pycardano. At least to get good ideas and / or functions.