032: Go cryptography with John Arundel

Dominic:

Hello there. I'm Dominic Senthien Pierre and you're listening to Go Podcast. Today, I'm talking with John Arundel on cryptography. So hello, Gophers. I have a guest this week and I'm receiving John Arundel.

Dominic:

So thank you very much for joining this, this podcast, John.

John:

Thanks very much for having me.

Dominic:

So I like to to start, by asking, you know, guests, what what are, you know, what are their their background and with a little bit bias towards go. So, I mean, obviously with, the experience that you are having, let's try to let's try to keep it short. I guess you have a lot of things to say, but, you know, for, for people, you know, how how would you describe yourself?

John:

Yeah. Well, I I usually say I'm a I'm a writer. And if people are still listening, I say I'm also a mentor. And they say, what's that? And they say, it's like teaching, but slightly less boring.

Dominic:

Nice.

John:

Yeah. So So anyway.

Dominic:

Yeah. So that yeah. I I like that a lot. So are you are you writing, for a long time?

John:

Yeah. I write GoBooks, basically. All of us, mostly what I'm interested in. And also a bit about careers, tech careers, how to how to survive in the tech industry. I mean, I have more or less so far.

John:

So, hopefully, I've got some useful insights or tips for people who are getting into the industry now, and also maybe, you know, a bit further on in their careers wondering how to survive it.

Dominic:

That's interesting. So I've I I I cannot, I I cannot not said something about AI. Is it is it something that that you you feel is is starting to take a little bit of concerns or I'm not sure how to explain that exactly, but are you seeing that as being more and more, a concerns?

John:

Yeah. Definitely. Everybody's really concerned about it, aren't they? It's you know, my students are asking me this as well, saying, is it even worth continuing with the mentoring? You know, is it worth me continuing learning to be a programmer if those jobs just aren't gonna be there?

John:

You know, is Devon gonna be doing it all? And my my answer is sort of while I hope programming is still gonna be an economically rewarding activity because that's basically the only thing I'm any good at apart from writing. And maybe books on programming won't be much use either, you know, if nobody's interested in doing it, but I think they will be. You know, programming is fun or it is if you're doing it right. That's my thesis.

John:

And that's what I try and teach people to do is sort of have fun programming and do it the right way. The trouble is maybe you need to get paid for something else. Right? So you can do do your programming in your spare time.

Dominic:

Yeah. Sure. Well, I'm I mean, yeah, this this is something that, kind of stood out when I kind of started to look at your profile and whatnot. You know, the word fun that you are keeping saying across is something that resonate a lot with me. So this is exactly why I'm doing that.

Dominic:

This is exactly why I kind of left my day job in 2007 to start my own company. I, you know, it's not like day job or borrowing or whatnot, but the the the specific one that I was doing was not very fun. So I I, you know, I I I do that for for those reason. And, the small amount of time that I've used AI, because I tried CoPilot for 1 month. There's a 1 month free trial.

Dominic:

And I told my wife something like, you you know what? I feel like I am the machine now. And and I I don't like that at all.

John:

Yeah. I know exactly what you mean. And I think it's really interesting to see what things like Copilot can do and can't do or what it's good at. Working with students after you know, usually pairing with them, writing some program, and a lot of them use Copilot. And I'll say to them, you know, what should we do?

John:

Add some method here, you know, load the data, and they'll start typing it and Copilot basically just fills it out. And they're sort of like, oh, sorry about that. I you know, I'm accidentally cheating by using Copilot. And I'm kinda like, I there's no cheating. I just think it's like, you you know, it's like your IDE.

John:

You know, if you have a refactoring function or something, that's use it. You know? Why not? What's the point of doing things the long way around? If it saves you a bunch of typing, why not?

John:

The point is, is it typing the right things for you? That's the question, isn't it?

Dominic:

Yeah. Oh, yeah.

John:

I don't think AI can answer that yet. I mean, it it does its best to know what it thinks you want, but it's not always right. And, actually, the really interesting thing about software engineering, I think, I don't know how you feel, is wanting the right stuff. You know? What should your product do?

John:

How should the program act? What do users want it to do? What's an elegant design? This kind of thing. That's the really hard part, and that's the bit I have fun with.

John:

Writing the code to implement that is kind of the easy bit.

Dominic:

Yeah. Understanding and understanding the goal of of a system. I I I I hear you on that for sure. Yeah. But on the other hand, for me, I mean, it's it's so fun when you have some kind of problem to solve at some point and you don't have the answer right away.

Dominic:

The amount of joy that I have when I finally get out of my frustration of searching for for a solution and completing it myself. This to me is is something that I I I'm not sure I'm I'm able to let go. This this feeling of accomplishment.

John:

I agree completely. It's it's fun for me. And, you know, often as a consultant, I would say to people, you know, client would have some problem. And I say, why don't we write a program to solve this? And they'd say, oh, that's a good idea, but, actually, we just found this software that that solves it already.

John:

So we'll just use that. Those feel really disappointed because I was like, oh, we were gonna write some software. Now we're just buying somebody else's product as a service. That's a shame. I mean, obviously, it's great for the client, solves their problem, and it's probably more cost effective.

John:

But I just like programming stuff. Sorry about that.

Dominic:

Yeah. Yeah. Totally. I hear you on that for sure. I mean but but yeah.

Dominic:

You know? And and when when I see things like, I don't know if you saw that, but it's making a lot of noise, in the last couple of days, especially on Twitter. The Devon thing. I'm not you know, I haven't checked that a lot so far. But, I mean, it seems to be I can understand that if I put me in the shoes of a younger developer.

Dominic:

Let's say I'm, I don't know, 18, 20, 20 years old. I fully understand because my kids are like that as well. They are not in the software engineering and whatnot. But they they are still concerned about that. Even even though they don't really know what they are what they are going to do, it's still, it's on them.

Dominic:

It's it's more on them than on than on us. I mean us. Bigger us, younger, older people. But you know, I I feel bad there a little bit for the young people.

John:

Yeah. I I do too. And I think, you know, listening to your interview with Chris Sheppard a while ago about GRPC and things, and you guys are talking about frameworks, and I think you both agreed. You know? One thing about Go is it it's a much more DIY friendly in that you you can just go ahead and write your app without having to import some vast framework.

John:

And the whole whole thing about a framework, of course, is it saves you from having to write all of that stuff yourself, REST API and things like this, which is great. But then as you and Chris were saying, you spend all your time debugging the framework instead of debugging your own code, which is much harder. And it's a bit bit the same with AI in that, you know, now if you want some REST API server, whatever you just say to chat GPT, please write this. And then you argue with chat GPT for another 3 or 4 hours until it understands exactly what you want. And then you just spend the rest of your time debugging that code that somebody else wrote.

John:

That's that's not a lot of fun for me.

Dominic:

Oh, yeah. Oh, yeah. Totally.

John:

Well, I think it's totally legit that some people, it's not a fun activity for them. They just need their problem solved with some software. And if it means they have to write it, okay, too bad, they'll grit their teeth and do it. AI is wonderful for people like that. I'm sure because it's just like, great.

John:

Now I don't have that difficult and annoying problem. I can just get the code done and go off and do something else. But for you and me and people who enjoy it as a fun activity, I think we'll we'll continue to do that. Right? And young people will too.

John:

If you're the kind of nerdy kid that I was that likes computers and so forth, you'll you'll you'll just want to play with them and do those things anyway, even if someone tells you, you'll never make a living doing that. You know, people still become poets and artists and dancers and things like that, don't they? Even though I'm sure their parents tell them they'll never make any money at it.

Dominic:

I I I would not really mind to not be being paid to to write software, to be frank. I I like that that much, but I I I appreciate some money for sure. So, alright, that's that's a good segment to, to switch, to our main topic for today. So I I have I have really enjoyed your book. And this is, you know, this is very true.

Dominic:

I don't know how to say that better than that in English, but, this is genuine. But I wonder, I mean, why did you choose the cryptography, cryptography topic for for this book?

John:

Well, that's a great question. I mean, I've I've written a few books in the past for publishers where they approached me and said, you know, we we really want someone to write a book that explains how to use Puppet or Kubernetes, you know, things that are notoriously hard to use. And I did that, but I thought it's not really what I wanna write about. I wanna write about programming, specifically Go, which is the language I enjoy programming in most. And so I thought, well, I I have to I can't just write about whatever I want.

John:

Right? Whatever interests me. I have to keep one eye on something that's gonna actually sell because this is my living now. I don't have a job. I just sit here hoping that people buy my books.

John:

So please do, by the way. So I wrote a book for total beginners who've never done any programming of any kind or know anything about Go or computers. It's called for the love of Go. Just because I thought that's the book I would have wanted when I was first getting into it. Just something that it that doesn't assume any previous knowledge and just says, let's just do some stuff.

John:

And then I thought, okay. That's that's the book that introduces you to Go. I did some more on command line tools and testing and things like this. And then I thought, right. Now I can write I've I've got those commercially minded books on the shelf.

John:

Now we can write about something that I just think is interesting, whether or not anybody's actually gonna buy it. I hope they do, but if they don't, it's not a disaster. And as a kid, I was obsessed with secret codes and spies, Sure a lot of kids are. Also trains and dinosaurs, but I haven't done books on those yet. But I'm still interested in secret codes and spies.

John:

And as you know, cryptography is actually everywhere in our lives in banking, Internet, software, computers, whatever. But it's it's just a black box. Right? We don't really know what's going on. We just hear the word cryptography, and it's like, fine.

John:

Okay. I don't don't understand how any of that works, but I just hope that it does. I thought it would be a fun project to try and find out what what is cryptography actually and what's it about. Not necessarily to teach you how to design your own ciphers or anything like that because I don't know how to do that. But just how do actual ciphers work, What makes things secure or not secure?

John:

How are passwords stored? You know? That's a mystery. How does a blockchain work? What is a digital signature?

John:

How does that work? All of this stuff is really fun to find out about. So I really enjoyed researching it and writing about it.

Dominic:

Yeah. Sure. And and and it it it shows in in the book for sure. And I I I was wondering while I was reading your book, I mean, how how much should they, you know, quote unquote a normal programmer should know about these things, you think? Is is encryption should be more present in our day to day, I would guess, task and whatnot?

John:

Yeah. That's a great point. I mean, I think you you can get by as a normal person completely without knowing anything about cryptography. Of course, people do. As a programmer, I think you you just use the code that's there, you know.

John:

In Go, you use the standard library crypto package, don't you? And, it all just works, and that's great. But I think there's a little bit of a danger there in that, you know, for years years years as a consultant program or whatever, whenever cryptography would come up in a discussion, I'd just sit there hoping no one asks me any searching questions about how it actually works because I knew I wouldn't be able to tell them. And I said, oh, should we deprecate such and such insecure cipher suite? And, they're like, oh, of course, as we all know, sha one is insecure.

John:

And I'm just thinking, what is sha one now? And why is it insecure? And what should we do instead? I really hope nobody asks me before I can Google this. So I thought, you know what?

John:

I'm gonna sit down and just find out what's going on under the hood of this stuff. And I I think that means learning to write some ciphers myself, like implement a cipher in Go, implement digital signatures, that kind of thing. Just not because I think that code would be any good. It's not, of course, but just so I understand it in my brain. And I think that's really valuable for other people as well in that they won't have that cryptography imposter syndrome sitting in a meeting thinking what the heck makes things secure or not anyway.

Dominic:

I like that. I like that a lot, actually.

John:

So I'm hoping people will will read this book and not necessarily feel like, you know, okay. I could go ahead and write some new cryptosystem or something because I don't think they need to. We have pretty good cryptosystems already. The point is just that, you know, I want people to feel confident that they understand the important principles, Not the details necessarily. You know, you don't need to know all the ins and outs of something like AES, for example.

John:

It's just helpful if you have a sense in your mind of what's vaguely going on. Absolutely.

Dominic:

Yeah. I I I needed to, to use, AES lately in a project because the and and this is a subject that I I want to keep for a little bit later, but suffice to say that, I mean, one one client of mine is storing kind of personal information and files and whatnot. I mean, those things should be encrypted. And, yeah. Like you said, even even though we are using the the crypto package packages in in Go, I mean, it's it's very, very interesting to, to have a little bit of background about how things work.

Dominic:

And I I appreciate that a lot.

John:

Yeah. You're absolutely right. I mean, this stuff comes up all the time, doesn't it? I mean, even though we're not implementing ciphers, we are storing stuff, private data, or, you know, sensitive information. We're also using authentication, authorization, that kind of stuff.

John:

And it's super easy to get wrong, isn't it? And the consequences of getting it wrong could be quite bad. So I think it's really helpful if people if you have a sort of a gut feeling about what how it works under the hood and why it's secure or not, I think that helps you use it more securely. And you could have the most secure cryptosystem in the world, but if you use it wrong, it's just no good. Right?

John:

Just like if you have the world's safest car, but then you just drive it into a wall. It's a great example of this is, you know, these come up all the time. But, Zoom, for example you know, Zoom calls are encrypted, but it turned out that they were using they were using AES, but they were using it in a a mode that's known to be insecure, in ECB mode. And it doesn't matter what that is. I explain it in the book, but I also explain why is that so insecure.

John:

And let's go ahead and actually break it ourselves by writing some code to investigate that. And then say, how can we solve that problem and what is a more secure mode for operating that cipher? If you it's it's all very well to just look that up on Stack Overflow, but I think it helps if you understand why you're doing things the way you're doing them.

Dominic:

Yeah. Absolutely. When, when I when I read that part in the book, I told myself, because you you gave you gave another example, and without without spoiling too much, please go buy the book, but this this piece needs to be needs to be told. I mean, if I recall correctly, you know, some companies, read some code, maybe on Stack Overflow and whatnot, and they kept the the I don't know, the the the the keys that that were used in the article. And when I when I wrote I read this, I was like, oh my, this is this is incredible.

John:

Yeah. They just it's clearly, they just didn't really understand what a key is. They're just like it's just a long string of hacks. So I guess this is fine. Right?

John:

We'll just take it from this tutorial and use that. Yeah. You know, I mean, we're laughing, but it's unless you actually understand at some level what's going on that, you know, for example, you need to keep the key secret. No good without that. It's you know, people are just sort of cargo culting a lot of this stuff, aren't they?

John:

Just copying and pasting. That's I'm sounding superior here, but I but I that's exactly what I was doing for basically my entire life until I sat down and started learning about this stuff. So I think it was certainly valuable for me. I hope it will be for someone else.

Dominic:

Absolutely. And, you know, I confession for confession, I I had to write, to wrote a kind of a shopping cart back. I think it was the first project I did when I completed my school, whatever. And, I think it was in, well, maybe well, 2,000 or 1999 maybe or 2,000. Let's say.

Dominic:

Let's say. So that not much cryptography in that time, I would say. I was I was writing code in classic ASP at that. Mhmm. And to be frank, I needed to, to take credit card and and I did not want it.

Dominic:

I I knew behind my back that, you know, taking credit card and saving that in plain text was not good. Even though the majority of the companies were doing that back in those days, which is crazy to say today. So without really knowing what I was doing, I built a Delphi program, which was a desktop, desktop application, which allowed the person that was selling it was it was it was selling cigar back then. The site was like aonecubancigar.com. I don't I don't think it exists.

Dominic:

But the point is, the the credit card was I I was just replacing numbers with, I I I don't think, I don't remember. Like, 8 or 9 I mean, special characters, if you will, which Yeah. Which was kind of the basic of of Ashing and whatnot. But I was I was not knowing what I I had, like, I don't know, 19 years old, 20 years old back then. So, I mean, when I hear what you are saying today, and yes, I think we there there's a lot of people that did that.

Dominic:

But when I when I read that on your book and knowing that we are still kind of doing errors like that today, it's kind of crazy which which bring to question, John, is is the Internet not secured today? I mean, this is crazy.

John:

Yeah. I mean, we have these incredible ciphers, you know, mathematicians working away in basements creating these amazing mathematical structures. And then people use some key from a tutorial. You know? So yes and no is the answer.

John:

I mean, we we have fantastic security technology available, especially in Go, real state of the art stuff. And people you know, most people are probably using it. Okay. But there's occasional egregious slips, which are easy to make. That's the point, isn't it?

John:

It's not like people are being dumb because they don't know everything about this stuff. Practically, nobody knows anything about this stuff. It's one reason I thought it's worth writing this book. I mean, one one example is, password rules. Right?

John:

Yeah. I'm sure you've encountered this on a website where you have to type in your password, and they say, no. You can't use that password because it doesn't fit our rules. You know? It's gotta contain at least 3 digits, 2 special characters, 1 uppercase letter, and things like this.

John:

And I always thought that was done, but I didn't realize until I looked into it that these rules are actually making your password less secure. I mean, that's counterintuitive. Right?

Dominic:

Yeah. This this is incredible because, after I I read that, I I never well, myself, I never really thought about that this way. To be frank, I I I haven't put much thought. But once I read read that and I think it was probably 5 days later, I was on the website which was asking me, you know what? You should have, I don't know, 8 characters, 1 And I remember, and I said, that's true.

Dominic:

That's so true. I mean, they are giving the I don't know, the rules to crack password in in plain English right there. It's crazy.

John:

Yeah. I mean, a good good way to illustrate this. There's supposed to be a password with just one character. And it could be any ASCII character, let's say. Well, you you've got, if someone's trying to break into that by just guessing, they've got a they've got 256 possibilities.

John:

But now if we say your password has to contain at least 1 digit, well, there's only 10 possibilities, so that's way easier. The bad actor would be really grateful for a password rule like that because it drastically cuts their workload. And it's the same for longer passwords, of course. And I think that this is what helped me is looking at the actual maths of it to see, you know, if we have suppose you have a safe with a 1 digit combination. You you just have to make 10 guesses in order to break into it.

John:

In fact, on average, you only have to to guess 5 digits because you'll probably find it halfway through. But if you have 2 digits, it's 10 times 10, and if you have 3 digits, it's 10 times 10 times 10 and so forth. And if you keep timesing something by itself enough times, it gets pretty big pretty quickly. Yeah. Which makes it which makes a really counterintuitive difference.

John:

You know? Suppose you have your AES key, for example, is, you know, 255 bytes, or 255 bits, you might think, well, how much extra security does adding one extra bit to it give you? A little bit extra, but not that much, surely. And the answer is it's twice as secure because, you know, for all of the 255 bits they had to guess before, now they have to guess them all over again, but with a one instead of a 0. Yep.

John:

Yeah. Yeah. So so if you look at, for example, how long it takes to crack a password by brute force using sort of today's computers, I think it's something like for a 7 character password, it's a couple of seconds. For a 14 character password, it's a 1000000000 years.

Dominic:

That's crazy. Yeah.

John:

Quite a difference. So it's worth typing those extra characters. You know, if you are gonna implement a password rule on your site, the best one you could do is just make it minimum 14 characters.

Dominic:

Yeah. Oh, yeah. Totally. And not being a dictionary words and whatnot, I mean.

John:

Yeah. Thanks for coming to my TED talk.

Dominic:

So what, well, in that case, well, it's it seems like we are still in a, I I don't know, a dangerous place even today. I don't know how to say that better. But what what our organization should do then to make sure that their security efforts is, I don't know, improving? And and and, I mean, is it is there's lots of smaller companies that just don't are not even there yet. So what what do we do?

John:

Yeah. That's a great question. I have no idea. Wish I knew. I mean, I don't have any expertise on this.

John:

I'm just someone who likes secret codes and spies. But I do think, you know, it it makes sense to just avoid storing anything private or secret as much as you can, isn't it? Because then you just make an end run around the whole problem. It's like optimization. You know, best optimization is just not to do the thing.

Dominic:

Yep.

John:

Store it in somebody else's service, then you can sue them if it leaks. You know, store it in AWS, and then you can sue Amazon. You know, they've got the money.

Dominic:

Oh, yeah.

John:

But if you do but if you do have to store stuff, it's it's worth knowing a little bit about these things. For example, you know, one one fun thing that I found out or while writing the book was, you know, thinking about hashing algorithms. We understand hashing is sort of a way to take some arbitrary block of data and then just turn it into a number, then you can compare 2 two blocks of data quite easily to say, are they the same data without having to actually send all the data? And that works for passwords too, but there's the special consideration wherein, you know, if if we're hashing data for things like comparing if 2 files are the same, you obviously want that algorithm to be really fast.

Dominic:

Right.

John:

And ideally hardware accelerated, and it usually is. But for passwords, I mean, hashing is also great for passwords because when I log in to some website, the browser can just send the hash of the password over the wire instead of sending the actual password. And then the bank can say, that doesn't match the hash I have. So, you know, no banking for you. But with, you know, with with passwords, you want your hash algorithm to be really slow.

John:

That's weird. Right? Why would you want it to be slow? The answer is, you know, the only people who need to hash a lot of passwords quickly are the bad actors.

Dominic:

Right.

John:

If I know the right password, I only need to hash it once. So that's fast. Even if it takes a second, I won't notice. Everything on the web takes at least one second. Whereas if I'm trying to hash a 1000000 passwords, the fact that it takes a second will be really annoying.

John:

It would really slow me down. So there are special hash algorithms just for passwords, things like s crypt and bcrypt. And you don't have to know how they work, and I don't know. But the point is if you know they exist, you're like, now I know which kind of hash algorithm to use for storing my password.

Dominic:

Yeah. Totally. I I I I believe that's that's why that's another plus for Go in in my opinion, because all the crypto aspect is just easy to use in my opinion, in my experience so far. Compared to to other stack. I mean, I I I come from the dot net world.

Dominic:

It's not that bad as well, to be frank, in in dot net world. But, I don't know. In Go it it just feels, I I would dare say even smooth to to use those things. Yeah.

John:

I mean, it's it's absolutely amazing because, you know, in the book, I talk a bit about AES and just explain what's going on under the hood. Like, what does AES do to obscure? The plain text, the answer is it misses and mashes those bytes around all over the place and combines them in elegant and impenetrable mathematical ways, which are very resistant to brute force and cryptanalysis and so on. And then when you look at the go code in the standard library that implements that, which I recommend, it's fun to read, makes your head hurt a bit because there's a lot of bit flipping and twiddling, and it's very efficient because it's based on lookup tables and so forth. But it's still interesting, but a little bit complicated.

John:

But then when you what the go code you actually have to write to use AES, it's so trivial. It's like 3 lines. And I I almost felt bad putting the example in the book because I'm just like, this is literally copy and paste it from the docs. It's like aes.new cipher, bug the key in, then just encrypt your stuff. And it all just magically works.

John:

Yeah. I think that's terrific. And then all you have to remember to do is not tell anyone the key.

Dominic:

Yeah. That's a that's a special, special thing. So where where are you putting your keys then while we are in the subject?

John:

Well, great question. I mean, the the thing is, it's as we've said, it doesn't matter if you've got the most secure cryptosystem in the world and the best code if your password is just password.

Dominic:

Yeah. I

John:

mean, that's or if you've written it down on a sticky note on your monitor. So the the question is, how how can you pick good passwords? And the answer would be they should be as random as possible, so obviously not in the dictionary as you said. And like you storing the credit card numbers, not much good just replacing letters with digits and so forth. That's easily brute force too.

John:

But, it it should be as random as possible, and we humans are not very good at being random, are we? It's really hard. The the harder you try to be random, the more you aren't. And, the best thing is just to use some random generator, you know, the one on your computer. The problem with that is, how do you memorize a string of arbitrary binary digits, 256 of them?

John:

That's pretty hard. Right? I love it. So, of course, use password managers and things like this. That's what they're for is precisely so that you can have long complex passwords that you could never remember.

John:

And if they're stored in your password manager, you you don't have to remember them, and you can't reveal them. You know, like, did you ever do this trick? I used to make all my passwords obscenities so that if anybody asked me to tell them the password over the phone, I'd be

Dominic:

too embarrassed.

John:

Interesting. And, this this does work until it's a customer or something, you know, and then it's a little awkward. But, password managers are fantastic until you find the the author of the website has disabled the ability to paste into the password field. So, again, probably meaning well. Right?

John:

I don't know what they thought that would help. But

Dominic:

We we do that for for your protection. That's what they say.

John:

Yeah. Exactly. So it's so I think, again, it's just cargo culting. They they probably just asked chat GPT what should I do to make my web app more secure. And chat GPT said, you know, insist on special characters and passwords and disable paste.

John:

But password managers are great. But if you have to if there's some password that you just have to remember, a great tip that I read is to think of some long phrase, some quotation that you like, or something from a poem or TV show or something and just use the initial letters of that phrase, something like that.

Dominic:

Yeah. Good tip. And what what about, what about server architecture? So let's say let's say there there's multiple, I don't know, services out there, and they do need to encrypt some data. Do you do you trust the, I don't know, environment variable, for example?

Dominic:

Where where are you putting those those keys?

John:

Well, I think it a lot of this is common sense, and most people have that. So they're not doing crazy stuff like storing passwords in plain text. And you you you can do that sort of stuff, but I think what's really important is just any code that you write is gonna contain security bugs and all the other kinds of bugs as well. I don't mean you. I mean, me too, you know, and everybody.

John:

So just like with regular bugs, it's really important to get somebody else to look at it because they'll be able to see, you know, the error in huge font that you've been overlooking, that you've been staring at it for hours. And and, similarly, with security, I think it's it's really worth, if your code is doing anything with security, get it reviewed by an actual sort of credentialed security expert, somebody who does this stuff for a living. There are people who just professionally find security holes in people's software and setups. And thank goodness. Because, apparently, there's a lot of them to find.

John:

This is a booming industry, isn't it?

Dominic:

Yeah. Yeah. Absolutely. This this is one of my questions. So do you do you do you think well, I've I've been I've been noticing that for the last, I would say, I don't know, 5, 6, 7 years, companies tend to be more concerned about security.

Dominic:

Well, compared to before before they there had to be a major, critical issues in an industry before other companies in that same industry to start, I don't know, be concerned about security.

John:

Yeah. I think it it's a bit like, in a sense, the technology is not a friend here in the, before frameworks and things existed. If you wanted to encipher something, you just had to invent a cipher and implement it yourself. And it would probably be terrible, but you'd be alright because nobody seriously wanted to know what was what your was hiding. But, it's, you know, now we have wonderful things like AES that you can just plug in and use.

John:

But if you don't understand how they work, you can accidentally use them insecurely, and that's really easy to do. So, you know, as as you say, we're we're all using cryptography and so forth a lot more and and encrypted services all the time. But we don't understand how they work. So it's not surprising we're occasionally holding them wrong.

Dominic:

Yeah. I I I think we we are starting to be better though. I mean, I I I've been seeing a lot of movement in this. And may maybe maybe I'm a little bit biased because I had a small pass at Equifax for some time. And I was not there prior to their, their big big fiasco, but I can assure you that for for the the little time I I I was there, due to an acquisition, well, it seems to be pretty secure these days.

Dominic:

But but again, they they needed they they needed some, some it in the face. They needed something big to happen. And now in in the in the current industry, now everyone started to, to pay attention. Oh, if they got cut, I mean, we haven't paid any attention to security for years.

John:

Yeah.

Dominic:

I I I I kind of see some, huge demand for security experts, as we as we advance in our society.

John:

Yeah. I agree. And I think you're right that it's people are more aware of this stuff because there because there have been so many high profile security breaches and leaks and things. And, people are more aware of the importance of this stuff, and they're more sophisticated about how they go about securing things. Unfortunately, the bad guys are getting more sophisticated as well.

John:

Right? They're they're probably buying my book too. I don't mind.

Dominic:

Sure. Unless they found some ways to abuse the system. If there is so I mean, yeah, I can imagine that they are also getting getting better and better, which which is kind of scary at the end of the day because, I mean, there's so much information out there. It's it's kind and and and again, I I I will I will I will return to that. But, the examples that you gave on on on the book, I when you don't really know and I'm a little bit guilty of not really following news and whatnot.

Dominic:

I'm I don't know. It's not something that I'm very good at, but to know that those bigger organization have such, I don't know, such bad practice even these days in security? I mean, this I don't know. I I I start to to ask myself, well, should I, I don't know. Should should I get everything everything I have on the Internet and just, secure that on my, unplug the machine at some place and a hard drive and whatnot?

Dominic:

I mean, this is

John:

scary. Yeah. I mean, you also have to consider who who is the adversary. You know? Who who is it that we're trying to protect this stuff from?

John:

And those people are pretty honest. So it's, you know, it's not like someone's probably gonna be trying to crack the password on your computer and, you know, read your appointments or something. But, things like foreign governments, you know, espionage, military secrets, all of this kind of stuff, that actually does have some real consequences if if that stuff's not secure. So the question you know, the thing is we we're in a fantastic place with cryptography now and that we have systems like AES, which have no significant vulnerabilities that we know about. There are probably a few we don't know about, but we don't know about them.

John:

So that's alright. But, you know, for for example, I mean, back when you were storing your credit card numbers for your cigar company, we we didn't have such great security technology available. We had things like DES, you know, which I think was 56 bit key or something like that. You know, something that would seem very small now. And part of the fun reason for that was, you know, intelligence agencies did not want people using a more secure cipher than that because then they wouldn't be able to read it.

John:

They'd like to make sure that they can read the encrypted stuff that everybody's sending around. That makes sense. Alright? That's their job. Sure.

John:

But all you have to do is use AES with 256 bit key, and not only will the government not be able to read it, but nobody else will either. And, do a little back of the envelope math in the book to work out, you know, how much time and energy is involved in cracking a key, Something like that. And I think it's, I read somewhere that the average energy released in a typical supernova is something like enough to enumerate, you know, a 128 bits or something like that. So you'd need a good many supernovas to crack that AES key. In fact, you'd need about a galaxy's worth.

John:

So imagine some future civilization, you know, which a a Kardashian type 3 civilization, which controls this controls the energy resources of an entire galaxy, and they they can throw them all into cracking the password on my zip file. You know? Must be something really interesting in there. But, you know, they have to burn up a galaxy basically to break this encryption. And that's that's the encryption I'm using today in 2024.

John:

You know? So I think that's pretty good. It's it's hard to think of some other area of technology in modern life that's as impressive as that, isn't it?

Dominic:

Absolutely. But it it it just needs to continue, I I think, spreading a little bit more because we we tend to see that the adoption seems to be there, maybe on on more bigger organization, but I still I still have clients that I don't know. They they don't they don't really see the benefits still to in inject some, some money in in security. I mean, it's still it's still not a super huge concern. And, and I I yeah.

Dominic:

I understand that, but they they could they could still they could still have a lot of problem. May maybe not breach, but just ransomware, which is terrible for a small company. So I mean Yeah. Yes. It still needs to spread.

Dominic:

And to my defense, for my old credit card, I mean, I don't even believe that people were ashing credit card back then. So they were they were kind of storing that straight plain text in databases Right. Which was We crazy.

John:

One of the first jobs I ever had as quite a young person programming was, working on a a sales system for telesales, and, people had to enter their credit card numbers. And as you know, credit card numbers have a check digit or digits. So you you take the first x digits and you do some munching on them, and then they should match the last digit for parity or whatever. And you can tell if you typed it in wrong. So so I read up this algorithm.

John:

You know, this was before Google, but I found out how it works. And, of course, the first thing we did was turn it around and use it to generate as many valid credit card numbers as we wanted. That's kids for you. And, sure, we we bought a lot of illicit cigars that way.

Dominic:

Nice.

John:

But it it's fun and interesting to know this stuff, and I think the same instinct that makes people want to break into their school computer network, you know, as I did, and I'm sure you did quite a few other listeners. Right? It's that's that same instinct. When you grow up, hopefully, you you become part of the white hat community, and you're interested in working out how to stop people doing that kind of stuff. Absolutely.

John:

Or same parts of your brain lighting up in both cases though, isn't it? I think.

Dominic:

Yeah. Totally. I I I did appreciate, though, in your book, the, the other way around. So you, you kind of make us create a simple, simple encryption and we build something to break it. You know, this is nice.

Dominic:

I will be frank, I'm not a huge, I don't know. I'm not a huge not fan. I'm I'm very fan, but I I'm not very knowledgeable of all of those things. And I never really I don't know. I I I think I I am I'm a white hat person, I would say, if you want to to take that analogy.

Dominic:

Never really really tried anything crazy myself. But, but again, I I I found it interesting to to build something to crack something that that we build on the book.

John:

It's Yeah. Me too. And I once had, you know, my boss had something in an encrypted word document with the password on it, and he forgot the password. He said, is there anything you can do? You know?

John:

And I said, yeah. I can write a brute force password cracker. Let's do this. You know? Well, that's wield the awesome power of Pearl or whatever.

Dominic:

Did it work?

John:

Yeah, totally. Oh. I mean, he he was delighted, but on the other hand, also a little worried. So, well, if it's that easy, You know, I said, ah, no. But you have to be a genius to write that program.

John:

Nice. I'm sure he still believes that.

Dominic:

The good old days. Cool. Yeah.

John:

It's really interesting and fun. And that's the point is I think if if you're a professional developer and you work with security and authentication and stuff, as I'm sure you do, then I think this book will be valuable to you. But even if but also and even if you're not, I think it's just cool.

Dominic:

Absolutely. Oh, yeah. Yeah. I I think I think, everybody should gain from reading the book for sure because, yes, I mean, basic knowledge is really great. And, yeah, I think for for me it was it was surprising how I was discovering things that I'm using every day, and I said, wow, this is interesting.

Dominic:

The the padding function, for example, that that that was that was one very, very interesting to me. Yeah. Awesome. When you when you have a key, let's say a 30 bit a 30 bit key, that that is not filled completely, What what do you do with the the remaining, bits? And I was like, I don't know.

Dominic:

I I don't know.

John:

Exactly. It's just these questions never even occurred to me before, and I'm slightly surprised to realize I don't know how to answer them. But it turns out, you know, you can design a batting scheme, which is very elegant and simple to write just a few lines ago. It works perfectly. And I didn't invent it, of course.

John:

Just looked it up. But that's really interesting. And I think, you know, let's normalize reading about stuff that's just interesting and fun and and writing programs that they're interesting in and fun just for the sheer mental joy of it. I think that's allowed, isn't it?

Dominic:

Oh, yeah.

John:

It should be allowed.

Dominic:

Should be. And, and and to me, at least, I'm now very, very interested to, to go a little bit, dive a little bit inside the the Go the Go packages and things like that. So like you said, AES might be might be interested. Not not of course I will not, you know, grasp anything and things like that, but just just my curiosity. Now I am curious about cryptography, which I was not really before reading the book.

Dominic:

Which is crazy because I like the secrets. I like the things that you were mentioning. But I don't know. It never really occurred. I've been build building too too many small businesses in in my in my career so far.

Dominic:

So I mean, it it was taking way, way too much of my time, I think.

John:

Yeah. I'm glad you said that. I hope it inspires a few other people to be interested and to learn more about this stuff. You know? For example, to learn about actual cryptanalysis and how to design ciphers and things like this so that then they can explain it to me.

John:

Sure.

Dominic:

Alright. So, cool. So alright. I think, I think we can wrap up with, with a closing closing comment. So I like to ask people, if there's anything that that they are missing in Go.

Dominic:

So maybe maybe you're you you talked about Pearl a couple of minutes ago. I mean, is there anything that And I understand that Go is simple and we all love the simplicity and and things like that. I I I really like Go as it is. But let's let's just I don't know. Let's just talk for for a minute.

Dominic:

Did you Yeah. Do you do you miss something?

John:

Well, I've I've used lots of different programming languages, over the years. And I think Go is one of my favorites precisely because almost everything is already missing from it. Yeah. You know? It's I mean, when when you're young and getting into this stuff and you you like, expressing yourself in beautiful, elegant code structures.

John:

There are languages that are optimal for that, where you can create almost any kind of construct you want and programming any way you want. You like object orientation, program that way. You like functional programming, do it that way. Great. You can do whatever.

John:

Go is definitely not like that. It's Go is more like this is the way you do it, you know. If you don't like Go's way, probably find some other language. But that's okay. I appreciate that now.

John:

I'm a bit older and got a slightly more pragmatic view of these things, especially because I teach it for a living. You know? It's very simple, less for me to teach. Easy money. Right?

John:

And to actually answer your question, I I don't I don't find myself writing go programs and thinking, oh, if only I had this keyword. You know? This would just instantly solve my problem. I mean, I I know people do think that, and they make regular proposals on the go issue tracker. Please just add this one keyword, and it will solve all my problems.

John:

They didn't realize, of course, it will create a 100 more. But never mind. I think one thing that really bugged me for a while was, let's say, I have some function, adds two numbers together, you know, and I say, func add x and y int, you know, returns int. Okay. What if they're float 60 fours then?

Dominic:

Or

John:

what if they're u ints? Or what if they're in 60 fours? Do I have to really, we have to write a separate function for each of those? Like, for every numeric type, I have to write another function with a different signature. And the answer is yes.

John:

That's just the way it is, But you can use code generation. Oh, great. You know? Now now I have even more problems because I don't understand how my code generation works. And I thought, that's crazy.

John:

Shouldn't it be possible to just write some function add of t any, you know, or t some set of numeric types where I can just add them together. And, you know, it turns out they've they've already added that.

Dominic:

Yeah. So you're a fan of generics after all?

John:

Yeah. Or or rather, I think that that was the only thing which tripped me up and thinking, this is weird. Isn't there a better way to do this? Don't let me down. Go.

John:

You know? Surely, there's some sensible way to do this with not too much typing. And they they do now have that. So that's a shame because now I have no good answer to your question. But that's Oh, no.

Dominic:

Well, it's it's it's pretty good. This this is interesting because I I was exactly like you about generics, and I find myself not really using them, once they are there. I don't know what's wrong with me.

John:

No. There's nothing wrong with you, and I think everybody feels the same. Okay. I I wrote another book specifically about this just to tell people how cool I think generics are, and they're not nearly as complicated as you might think or fear or as it sounds. And one of the quotes I I used in there is from somebody who said generics is an incredibly interesting and useful addition to the language that I'll probably never use.

John:

And I thought he's absolutely right. I mean, it is super cool when you see what they've done and how they've done it. It's so go like, Just the absolute minimal extra syntax, but it opens up a whole new world of different ways of programming, you know, functional programming, map, reduce, filter, all of that kind of thing. Right. Generic types and collections.

John:

Absolutely wonderful. But I think people actually don't know about it. It's just, you know, they didn't get the memo or whatever. And you still people still see people complaining on Twitter. Go doesn't have generics.

John:

You're kinda like, I have news. Oh, yeah. And, they say, oh, but it took them too long to add it or whatever, so I'm still against Go. Never mind. Not gonna let Go no matter what they add to it.

John:

But I but I think people who have heard of generics just think that sounds like something complicated. That's not for me. You know? That that's for experts. Right?

John:

Senior developers, whoever they are. But but I think it's just it's something that's interesting and fun and quite easy. So I wrote the book just to say, here's some cool stuff we can do with generics. It's called no go generics.

Dominic:

Nice. Oh, yeah. Totally. Yeah. It it's very nice that they are there.

Dominic:

I I used them a couple of times, to be frank. It's it's just that I I don't know. It it feels like, sometimes I even though the the readability is is good, I still I still sometimes prefer to, I don't know, to use the good old way.

John:

Yeah. Well, the the thing is it's not so much that we want to write generic functions, although that's nice. I mean, unless you're writing some kind of general purpose library for people. You don't need to write an add function that takes any numeric type or whatever. You just add the types that you have.

John:

Right? If if you have a couple of int 64s, you can just add those together. No problem. No need to be generic. But it it's kind of nice to be able to write, generic types, a slice of t, you know, of some type t, especially if you're writing something like, a cash or some kind of store or key value store or something.

John:

You can just really easily make it generic. But the super nice thing is the APIs that it enables for regular users like you and me just want to use the standard library, you know. Again, think about the math package. You know, everything is float 64. So if you wanted to do min of 2 numbers, you have to cast them to float 64 first.

John:

That's really annoying. Why do I have to do that just to know if 2 is less than 3? Because we now have min and max built in. That's great. But they they can now build a whole load of totally generic APIs in the standard library, which solves a lot of that problem, takes away some of the boilerplate, And, also enables some really cool new language features, which just would have been impossible to do without them, such as iterators.

John:

Yep. Iterators are super neat. And in fact, in the second edition of no go generics, I added a section on iterators even though they're not in yet. It's coming. Still still just a pro a proposal and experiment.

John:

Right? The range over funk experiment. Yeah. But it it's so neat. I just can't stop talking about

Dominic:

it. Oh, yeah. Yeah. I'm with you with that. It's very it's very interesting, John.

Dominic:

Maybe, maybe we we should, we should schedule another call at some point. Really, really appreciate your topics and whatnot.

John:

Sure. That'd be great.

Dominic:

Cool. So is there anything, that I missed? Do you have, you know, something that you want to say to listeners? Obviously, we will have all the links in the show notes. But, I mean, it's it's it's the time to, to say a last thought or something like that.

John:

I don't think so. I think I've said it all at great length. And thanks for your patience in listening to it.

Dominic:

Thank you very much. Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast. It's it's always helpful.

Dominic:

Also, another way to support this show is by purchasing my course. There's always a link in the show notes. So on that, see you next week.

Creators and Guests

Dominic St-Pierre
Host
Dominic St-Pierre
Go system builder - entrepreneur. I've been writing software systems since 2001. I love SaaS, building since 2008.
John Arundel
Guest
John Arundel
Go mentor and author, 'Explore Go: Cryptography' and other stories. Programming is fun, and you should have fun.
032: Go cryptography with John Arundel
Broadcast by