Re: [BUG][FIX] Re: NEWSCARD * Publish and fetch permanent named records via Network News

On Sun, 9 Feb 2025 13:43:12 +0100
Stefan Claas <[email protected]> wrote:

> Byrl Raze Buckbriar wrote:
> > 
> > The git repo now has a bug fix commit:
> > https://codeberg.org/OCTADE/newscard.  
> 
> Thanks!
> 
> > > Secondly, I have to use for each posting a different password, which
> > > I do not want to do.  
> > 
> > This is mandatory, and is the entire point of the scheme. It is a unique, NAMED record. You publish the record with the unique key. Then anyone else you reveal the key to can pull the record. If you use a large, random key, the record cannot be decrypted by anyone without that knowledge. If you reveal the key, anyone can fetch and decrypt the record.
> > 
> > I initially conceived the scheme as a way of having a large signature without including it in news articles. Instead the signature line would have just the newscard key. Then anyone could pull it and see the encrypted file decoded to plaintext. As an example, try to pull newscard 'octade'.
> > 
> > The key or passphrase is run through a chain hash stream to generate the message-id That will be used in the NNTP article, which is how the record is retrieved. Every NNTP server I have ever tested honors this convention. I have zombie code placeholders for the eventuality of that yowie. Then I will implement a check to ensure the NNTP server has stored the article with the given message-id.  
> 
> Ok. I can fix this by using my nora program, which generates deterministic
> nonces, which can be used as passwords, so that Alice and Bob can generate
> for each day a lot of them and they don't need to exchange them, while
> using a share secret.
> 
> https://github.com/706f6c6c7578/nora

I know what you are saying. I would use a hash function to hash a shared secret with a nonce appended or prepended, or both. Then one can send the nonce along with the message, encrypted with the nonced shared key. Newscard actually does something like this by generating a random salt and encrypting the random salt with the Newscard derived key. That salt is the first string of encoded payload characters between the asterisks. The salt is decrypted and used to reproduce the secret key stream, so that the same message will form a radically different ciphertext even if the same passphrase is used. Plus it also genrates 9 salts for use with openssl encryption. Each message is encrypted with 9 hash-based keys, 9 salts, and 9 randomly-chosen key derivation iteration counts for the chacha20 cipher. I designed it to be a beast with serious overkill for the fun of it. I really like chacha20 for this kind of stuff.

I would like to add some functions to do what you are suggesting (shared key scheduling), allowing in-app shared key management ... but not this month. I need to wait until some more of the bugs are found in this doodleware before I risk creating more bugs. Stress test it all you like and try to break things if you will.

You might also try to post some test messages using tuff mode and reveal the keys publicly, so others can try to 'get' and 'show' them, and see if they encounter any bugs on their individual platforms or distros. The 'tuff' keygen in the script is very much overkill, too. When it generates a random key, it makes sure it is gangbusters bonzo bonkers random.

I wonder if it is possible to craft a encrypted message that will decrypt as a shell bomb, exploiting the shell or grabbing an unauthorized path in the script. I think that 'less' in standard terminals is pretty secure against such stuff, but someone might find a way to hack into a file path before it gets piped to less. That is not my area of expertise so any suggestions or breaks would be appreciated.

This project has taught me that BASH can be like weepy dynamite if not handled very carefully. Yet it is just too convenient with all the GNU userland tools and crypto toys to abandon BASH for a low-level language. Hello, foot gun ... meet knee gun.

> 
> Regards
> Stefan
> 
> -- 
> Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC
> ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
>  age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum