ccurl

e was a controversy about the homebrew "Curl-P" hash function (P supposedly means Prototype according to the author Come-From-Beyond, previously involved with NXT). After a bumpy responsible disclosure process, MIT researchers Neha Narula et al published these findings: https://github.com/mit-dci/tangled-curl/blob/master/vuln-iot... and an accompanying Medium post. IOTA Foundation dismissed the vulnerability as non-practical, but switched part of their crypto to Keccak instead: https://blog.iota.org/curl-disclosure-beyond-the-headline-18... So in the IOTA codebase, there is now "curl" (not to be confused with the HTTP library), which is based on the proprietary crypto, and "kerl", which is based on Keccak. Curl is still used for the PoW while I think kerl is now used for other signing. Here is a C implementation that is interesting to browse: https://github.com/iotaledger/ccurl/tree/master/src/lib A bit of an odd aspect of IOTA is the legacy of a ternary number system that is used in the crypto functions. That's why you have to convert your payloads to and from a base-27 encoding scheme ("trytes", alphabet [9A-Z]), which felt strange for me when I wrote some proof-of-concept code trying to use the IOTA libraries. Instead of switching to more established encoding schemes, the IOTA team defends this choice by pointing to future mystery hardware accelerators ("Jinn" etc.) that are supposed to use this ternary system for more memory-efficient calculation. A purported long-haul strategy that is sometimes mentioned is the distribution of such custom processors by IOTA in the future targeting embedded hardware. As an FPGA/Hardware developer myself, I'm extremely skeptical about all of this voodoo and do not understand why so many people seem not to mind it, especially the industry partners like Microsoft and Fujitsu. It would certainly help if the IOTA foundation would disclose more details about these mystery machines. In summary I find the general approach of IOTA interesting and worthwhile, but there are some strange aspects in the software (not to mention all that coordinator business and the full-system-snapshots that lose all message data once in a while) that I wish would be thoroughly addressed by employing more KISS principle and less NIH.