• 4 posts
  • 13 comments
Joined 3 years ago
Cake day: August 31st, 2023

Today I found the weirdest bug in my life. I was making a chatbot for Signal using Ollama in Rust. I finished a basic demo and tried it. For any message I would get { }, {}, {} or { } .

Do you know how hard is to debug something like this???

What was the problem? Not my program. Ollama bug combined with ollama-rs bug (rust library for ollama). And both bugs are not even bugs if you don’t combine them.

Ollama released a new feature yesterday called “Structured outputs”. Basically you can specify a format of the output using format field in json request. Format field already existes for something but I don’t know for what. In ollama-rs you can specify the format to json or leave it empty. By default its empty. Where is the bug?

There is a difference betwen "format": null and not specifying the format at all. Ollama-rs will set format to null if you dont specify it. Ollama will interpret null as a valid format. What happens? LLM WILL ACTUALLY GIVE YOU FORMAT OF OUTPUT AS NULL - { }!

  • I switched from Docker to Podman, because Podman is more secure (if rootless) but it was just hard to autostart containars. You have to start one by one because they don’t have a central service like docker. And watchtower and nextcloud AIO don’t work on Podman. So I switched back to docker.

Hi, I’m working on a PQC key establishment and authentication protocol. Currently it works like this:

  1. Client and server each generate ECDSA and Dilithium identity keys and share them between each other, with usb for example.
  2. Client sends to the server single-use ECDH public key, single-use Kyber public key, timestamp, ECDSA and Dilithium signature of everything before it.
  3. Server verifies the message using clients identity keys, generates 2 secrets, one from ECDH and one from Kyber and then it uses blake3 kdf to derive a key from both secrets. Then it sends response with single-use ECDH public key, Kyber ciphertext, timestamp, ECDSA and Dilithium signature of everything before it.
  4. Client verifies the message using servers identity keys, and generates 2 secrets, one from ECDH and one from Kyber ciphertext and then it uses blake3 kdf to derive a key from both secrets.

Kyber: kyber1024 ECDH: secp256k1 ECDSA: secp256k1

I will use the key for XChaCha20-blake3 aead. I don’t know yet how will I generate and keep track of used/unused nonces.

Building this was interesting and fun, but I want more. How can I improve this key exchange, make it more secure, faster, and smaller? Both messages are huge (6268 bytes), because of Kyber and Dilithium.

Any ideas for what application could be this used?

Hi, currently I have a almost none backups and I want to change them. I have a PC with Nextcloud on 500gb ssd that I also use for gaming (1tb system drive). Nextcloud would be used to store/sync images, documents, contacts, and calendar from my phone and laptop. I also have an old pc that has 2x 80gb, 120gb, 320gb, and 500gb hdd. I want to use it for other backups like OS snapshots, programming projects, etc. but its not a big hdd but a lot of small hdds. Should I store each backup on 2 drives? Can I automate this? Any suggestions would be helpful.