cipher-aes
ed25519
| cipher-aes | ed25519 | |
|---|---|---|
| - | 22 | |
| 22 | 22 | |
| - | - | |
| 0.0 | 1.5 | |
| almost 5 years ago | about 1 year ago | |
| C | C | |
| BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cipher-aes
We haven't tracked posts mentioning cipher-aes yet.
Tracking mentions began in Dec 2020.
ed25519
-
How to Design an AI Agent That Survives Infrastructure Changes
Ed25519 keypairs make this practical. The keypair is generated once and stored on disk. The public key becomes the agent's canonical address — derived from the key, not from the network, so it survives every infrastructure change automatically. When an agent restarts on a new host, it loads its keypair and presents the same public key it always has. Peers recognise it immediately. No re-registration, no manual update, no downtime for relationship re-establishment.
-
The Agent Space Is About to Have Its TCP/IP Moment. Here Is What That Means for Builders.
Persistent addressing. IP addresses change. Agents restart, migrate between cloud providers, run on spot instances that get reclaimed. An agent's address needs to come from something stable — specifically a cryptographic keypair that lives on disk. The address is derived from the key, not the host. It survives every infrastructure change without any external coordination.
-
MCP, A2A, and Pilot Protocol Are Not Competing. Your Agent Stack Probably Needs All Three.
Pilot Protocol is the network layer that sits underneath agent-to-agent communication. Each agent runs a local daemon. The daemon assigns the agent a virtual address derived from its Ed25519 keypair, handles NAT traversal so agents behind different firewalls can reach each other directly, and encrypts all traffic with X25519 and AES-256-GCM.
-
My Agent Has Been Running for 60 Days. It Has Never Had the Same IP Twice.
In Pilot Protocol, each agent's address is derived from an Ed25519 keypair that lives on disk. The keypair is generated once when the daemon first starts. The address is a mathematical function of the public key. It does not come from the network. It does not come from the machine. It does not come from anything that changes when the agent moves.
-
I deployed AI agents across AWS, GCP, and Azure without a VPN. Here is how it works.
The identity layer sits on top: agents authenticate with Ed25519 signatures before the encrypted channel is established, and trust is mutual. Agent A can trust Agent B without either having access to anything else on their respective networks. This is the least-privilege model VPNs cannot provide by design.
-
"YOLO" is not a valid hash construction
Software engineers should be made aware of such pitfalls, but I don't think a whole course is necessary or useful. It's very easy to build encryption that you can't crack, especially because the "types of attacks" is a truly endless font.
It's probably more useful to have a module within a course to discuss the current state of the art and learning some history about how the methods were chosen (e.g. NIST's AES, SHA2/3, and PQC open processes. I think making it very obvious that there are extremely good, quality, free tools out there would reduce the likelihood of someone DIYing some crap.
That said, I once spec'd using Ed25519 asymmetric signatures for webhooks sent out to customers, and later on one of our Elixir developers was complaining that the throughput was garbage. I was confused because https://ed25519.cr.yp.to/ boasts signing rates of ~27k/sec/core on very old hardware. Turns out they were using some "pure Elixir" library which had shit (over 1000x worse) performance. There wasn't any real surface area for attacks here, but there are plenty of devs who will blindly search package-manager-of-choice for an otherwise good encryption and get screwed. Not sure who blame in that scenario.
-
NIST Announces Post-Quantum Cryptography Standards
From https://ed25519.cr.yp.to/:
> High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers, etc.
-
Joining ChatCraft.org
The first step was to generate an ed25519 - ssh key for my Github account.
-
GitLab: Authentication and Signing with SSH Keys
From the GitLab documentation, ED25519 keys are recommended, as they are more secure and performant than RSA keys, according to the book Practical Cryptography With Go.
-
The Algorand Community Study Group just had our first meeting yesterday. We read Chapter 15 Elliptic Curve Cryptography in A Graduate Course in Applied Cryptography (Boneh, Shoup). Are you interested in learning applied cryptography? Which topic should we cover next? Come join us!
Correction regarding Ed25519: The Edwards Digital Signature Algorithm (EdDSA) https://ed25519.cr.yp.to/ was developed by a team including Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. The first paper came out in 2011.
What are some alternatives?
blake3 - official implementations of the BLAKE3 cryptographic hash function
secp256k1 - Haskell bindings for secp256k1 library
PBKDF2 - WARNING: This package is broken. Do not use it.
cryptohash-sha256 - Fast, pure and practical SHA-256 implementation
entropy - Easy entropy source for Haskell users.
lol - Λ ⚬ λ: Functional Lattice Cryptography