Keep in mind while developing your new algorithm that it needs to be more than just secure. For anyone to actually want to use your algorithm, it will have to be more desirable to use than existing algorithms. For example, AES is optimized for hardware usage. Intel chips even implement AES instructions at a hardware level. Your algorithm would have to be faster than this and at least as secure for anyone to consider actually using it. That's a big task!

Before you start, I encourage you to learn how DES was broken and see if you can do it yourself. Have a look at TEA and XTEA. Learn about Feistel ciphers. Learn the differences between DES and AES. Write some programs that actually use these primitives. Learn about block ciphers and what an IV actually is. Learn about AEAD block modes like GCM. You should use and abuse crypto before you try to make your own! Good luck!

Also, might be worth reading about asymmetric cryptography a bit more, your description of Cape desrcribes it as asymmetric which is not the case at all. I didn't realize how much attention this repository had gotten before anyone noticed how broken it was. You should probably get in touch with those who have starred/used this code.

Ciao @luke-park the main motivation why I started experimenting with this algorithm was to have a really light and fast cipher to permit limited microcontrollers like ATmega or ATtiny family to be able to execute encryption/decryption in cases where a short execution time is required.

Considering my experience in the field and the available resources of devices where this was experimented on, the result couldnt be nothing more than a toy cipher as was correctly described on reddit :)

Sad to discover following your pointers how toy ciphers have been badly implemented in production and have caused many problems to users and providers. The funniest seems the story of the Somfy blinds: https://pushstack.wordpress.com/2016/03/06/control4-driver-decryption/

I also looked into different light weight ciphers for the IoTempower IoT framework - but wondering now if I should adopt PJON first.
Being more of a software architect than a security expert, I did really like the ChaCha cipher for embedded devices: https://en.wikipedia.org/wiki/Salsa20

Couldn't that be used for a potential encryption layer on top of PJON and used here in Cape?

Ciao @ulno thank you for your support, and sorry for the late answer. ChaCha for sure looks a sane choice, I have temporarily interrupted the effort on Cape to before make the network layer mature and reliable.

It would for sure be nice to offer a simple and flexible library that supports encryption over PJON. For example, like PJON has strategies here in Cape we could also have an entity to abstract in a class the cipher, and so provide with a list of ciphers with their pros and cons.

Could it be done like this? https://www.airspayce.com/mikem/arduino/RadioHead/classRHEncryptedDriver.html

Do you mean to have a higher level class that inherits the PJON strategies, who takes care to encrypt data? As in radiohead the encrypted driver inherits the generic one?

@ulno that would mean to place encryption at layer 2, it would be possible and even beneficial to add additional security for some of the strategies like EthernetTCP, LocalUDP, ThroughLoRa or ThroughSerial but strategies like OverSampling, SoftwareBitBang or AnalogSampling could not support that. So it may have sense to propose encrypted versions of some strategies, that inherit the standard classes and add the encryption feature.

At the same time in many cases may be more handy to have a class to be placed on top of the stack of all layers, before the user application, as the OSI model specifies.

Maybe the same class could also be used to implement encryption at layer 2.

What do you think?

I actually don't have strong feelings about the architecture (in spite of being a software engineer by training). I just liked the use of the ready available blockciphers here in Radiohead - even if I like how small ChaCha is.

I think PJON users might mainly care about having a very easy way to add symmetric encryption to any (also to the wired ones), with a simple addition to the connection setup.

So I think in terms of an enduser's perspective it would be nice to be able to just say for each specific destination node with just adding a key (and maybe having a default blockcipher) (like in add_node for Ethernet). Eventually the key could also be bound to the own id. But own key (for receiving messages) and the used blockcipher could also be specified via #defines or templates if that limits compile space. I think it would be more important to allow encrypted peer2peer communication than encryption of a bus where multiple peers are connected - not sure what to do about broadcasts then (maybe they loop through the sets of different peers and respective and only emulate?)

I know that breaks the idea of binding it too tightly to PJON, but I still vote for convenience a the least of amount of extra effort to achieve security and encourage people to use it.

Ciao @ulno I agree with you, arduinolibs contains a lot of cool MIT licensed software, on the other side, I am not sure to be able to evaluate the correctness and the absence of flaws in all those algorithms, it may have sense to start with the simplest to read and implement, and build a base class with common setters and getters as you suggested.