Blockchain, bad data, and bad code
[The scuttlebutt news are also available via the DeepSec scuttlebutt mailing list. This posting was sent to the list on 11 January 2022.]
the pandemic is still not over. 2022 greets us with a new variant of SARS-CoV-2. I hope all of you stay safe and stay healthy. The organisation of DeepSec events continues. The wonderful world of IT has plenty of topics to research and check for security vulnerabilities.
There is one issue I would like to describe in some more depth. DeepSec itself and parts of its staff and helpers have strong ties to cryptography. We supported the Crypto Party events in Vienna back in 2012. Back then, Bitcoin (₿) was three years old. It was regarded as a curiosity. For us, crypto still means cryptography. We considered accepting Bitcoin and other “cryptocurrencies” for buying DeepSec tickets multiple times. Every time we decided against it. The whole concept is not well designed and lives off the surrounding hype. In case you have read about the term Web3 somewhere in the Internet, this is a new “vision” dreaming of a decentralised network that will recreate the Internet as we know (i.e. the Web2). The concept raises more questions than it answers (as do “cryptocurrencies”). If you are interested in doing any security research about the ideas, please read some blog articles by Jamie Zawinski first. He has raised and explained some issues around “cryptocurrencies” and the Web3. He also has strong opinions, but this is something I also recommend. You can find a good starting point with these articles:
Of course, xkcd has some thoughts about Blockchains as well: https://xkcd.com/2030/
Another focus of our activities in 2022 will be the wonderful world of education. I am actively involved with teaching students IT security, basics of operating systems, basic programming, and secure coding. Over the past 20 years, many technologies have enriched software development. Teaching, however, is harder than ever. The new year has greeted Microsoft Exchange servers with an inter overflow because of the current date. Processor registers are only bigger than in the 1980ies, but they are still limited. Using secure programming languages is not always the answer, because programmers can’t change their toolchains every two years. Having code in libraries that is 20+ years old and well tested is an asset, if you know how to use it. So one aspect of the coming call for papers will deal with the way we need to convey solid knowledge to specialists in IT who are trying to fix things and write new code. To make matters worse, using search engines to solve basic problems on a platform you are trying to learn yield 80% to 90% of incomplete, wrong, or bad answers. I tried it myself with some answers regarding a sensor project on different ESP32 and ESP8266 platforms. Building well designed code on bad input or equally bad components (this is an article on its own) won’t work.
Speaking of programming languages, what is the difference between data science and mathematical statistics? Data science uses Python, the latter uses R heavily. It is a joke running around in some scientific communities. The quintessence of the pun is the handling and the context of data. We will explore the use of metrics and the role of data in information security. A lot of decision require a solid foundation in terms of measurements and data. So if you have some ideas about how things can go wrong (or even did) when information security decisions are based on wrong metrics and data, let us know.