[it also gives you an option to do it kindly, explaining to everybody what is going on, and letting them make a killing too if they're able to and interested] [it does sound really not good though, for everybody to have their plans not work [confused, how is this a mistkae? maybe it is? basically we want people ot be happy, but not for bad things to be happening; it's sad the lack of general communication, very very sad; maybe the addition of communication is helpful dunno :)]] uhh the information on akash rates is that a provider costs like $10 for a straight month and that can be broken down into tiny subcents for just a few minutes of use, so it's very cheap to just run a process on a remote host

and the $10/mo is for the random server specs i have put into my test yaml. it likely costs more or less for different machines :S sorry

I'm trying to write a small akash client. While discerning part of the protocol, I posted the three-post https://lists.cpunks.org/pipermail/cypherpunks/2023-July/115544.html which describes a potential vulnerability where a mitm can fake servers. I have not tested it, and am using a compromised system that often indicates mutated web content. I opened an issue for it. Curiously, I also looked up certs the other way around -- server validating client. I don't see this being done either, but have looked at it less in depth. This second option would be very serious as any old person could log into anybody's server, and hence it's pretty unlikely that I'm seeing it correctly, and one could infer from that the first vulnerability may be nonexistent too. But it's possible they're there! The usual way to check a vulnerability is to try to exploit it. It's very hard for me to spend time pursuing tasks, so I have not done this at this time.

contraposing: - akash works with an experienced security auditing team to vet providers - the akash code appeared to me to not validate certificates for offchain communications

On 7/20/23, Undescribed Horrific Abuse, One Victim & Survivor of Many wrote:

[i get 'could not resolve host' trying to visit the akash auditor's website, https://www.moultrieaudits.com/ ]

[ i briefly visited the website more than a month ago and it loaded. ]

if we can relax around it, maybe we can find a way to report possible vulnerability [if present]

boss: "that idea is icnredibly stupid too !!! yes, so long as camera is on."

the below text was unsent from 1 day ago: I reviewed the first issue again. [ insecureskipverify

really, it's very likely, given my prevalence of mistakes, that i'm just missing how the verifications are performed

[[[[i'm sorry it's not really example code for cert verification if such is sought, it uses homebrew libraries i wrote this past month [in https://github.com/xloem/smallcosmoscript or such] ]]]]

[[[[[[[[[[[ the grpc code depends on my fork at https://github.com/xloem/cosmospy-protobuf/tree/grpclib-akash . each grpclib branch is a different package. with that installed, `await small.client.Client.acreate()` then makes a general-purpose asyncio cosmos chain client. it creates member functions for all the calls at construction time. ]]]]]]]]]]]]

------------------------- [to repeat the problem, when i reviewed the provider client and server code for akash (partial report linked in second reply to [crazy?] tagged thread on this list) i did not see them verifying the other party's certificates. [this means a malicious party could log in]. _i make many mistakes and see many things wrongly_. the server code really looks wrong. [my highly paranoid guess as to what is wrong is that the certificate verification code could have been excised.]]

i bumped myself again i'm working on the raw p2p protocol. the cometbft/tendermint protocol really prioritized resisting mitm and node isolation; [you can identify the address of every peer] [and this address is then used to generate the network session keys for communicating with them]. It's so satisfying to be working with a network that does that. The bump is the the tendermint servers have a behavior where they reuse frame memory for efficiency, and keep frames a constant size [but don't write padding bytes] -- {the data is encrypted with somebody else's ephemeral key though}

it is nice that i am old enough that somebody is saying this clearly and overtly: https://github.com/tlsfuzzer/python-ecdsa#security **This library does not protect against side-channel attacks.** Do not allow attackers to measure how long it takes you to generate a key pair or sign a message. Do not allow attackers to run code on the same physical machine when key pair generation or signing is taking place (this includes virtual machines). Do not allow attackers to measure how much power your computer uses while generating the key pair or signing a message. Do not allow attackers to measure RF interference coming from your computer while generating a key pair or signing a message. Note: just loading the private key will cause key pair generation. Other operations or attack vectors may also be vulnerable to attacks. **For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key**.

On 7/30/23, Undescribed Horrific Abuse, One Victim & Survivor of Many wrote:

On 7/30/23, Undescribed Horrific Abuse, One Victim & Survivor of Many wrote:

...

it is nice that i am old enough that somebody is saying this clearly and overtly:

https://github.com/tlsfuzzer/python-ecdsa#security

**This library does not protect against side-channel attacks.**

Do not allow attackers to measure how long it takes you to generate a key pair or sign a message. Do not allow attackers to run code on the same physical machine when key pair generation or signing is taking place (this includes virtual machines). Do not allow attackers to measure how much power your computer uses while generating the key pair or signing a message. Do not allow attackers to measure RF interference coming from your computer while generating a key pair or signing a message. Note: just loading the private key will cause key pair generation. Other operations or attack vectors may also be vulnerable to attacks. **For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key**.

why cipherpunks write code: Somehow this information seems easily forgotten. What is possible in the world is based on what can actually be done. Generally, this is different from what people _say_ is possible, because they haven't tried it. Code shows what, on a computer, is possible. People who write code, see that many many things are possible. So, long ago, there were arguments around what was relevant or not, for example whether or not it is appropriate to secure a system. If you are familiar with writing code, you can tell whether a system is vulnerable or not, and know how easy it is to engage that situation. If you aren't, you are likely to instead be parroting misinformation from an oppressive body that is infiltrating things. Things that can be done by code can be done by _anybody_, _if_ they learn to write code. This is still true if a language model is writing your code for you.

Nowadays we understand more clearly that many spy agencies will send people into security groups (there is a history of trying to send people into _all_ groups), and spread this misinformation, disrupting productive conversations on what is important to protect everyone's safety. We also understand more clearly that these people may have undergone intense trainings that cast misinformation as harshly true for reasons of protecting security.

This misinformation pales in the face of real code, because real code says and demonstrates clearly what is actually real. Similarly, since _anybody can learn to use real code_, it is what is appropriate to protect against, when protecting security.

This is why this project posts this information, and it is why the tendermint protocol cryptographically verifies every peer. Because what is possible, can and does actually happen, no matter how much misinformation is spread.

And the only way to see that clearly is to get into the code, look for yourself, and write some code, and try it.

Completely dropped this part: Because it is so easy to show what is true with real writing of code, the behavior of these oppressive bodies has been to suppress intelligent and free engagement and discussion of code in general. You can see this some near public security audits ... This is maybe most clearly prevalent in the history of this list, and its present state. Where I am the only person on it discussing writing code.