Method of exchanging cryptographic keys
POPULARITY
3 episodes with diffie hellman
2 episodes with diffie hellman
2 episodes with diffie hellman
2 episodes with diffie hellman
10 episodes with diffie hellman
2 episodes with diffie hellman
2 episodes with diffie hellman
Martin Hellman is an American cryptographer known for co-inventing public-key cryptography with Whitfield Diffie and Ralph Merkle in the 1970s. Their groundbreaking Diffie-Hellman key exchange method allowed secure communication over insecure channels, laying the foundation for modern encryption protocols. Hellman has also contributed to cybersecurity policy and ethical discussions on nuclear risk. His work has The post Turing Award Special: A Conversation with Martin Hellman appeared first on Software Engineering Daily.
Martin Hellman is an American cryptographer known for co-inventing public-key cryptography with Whitfield Diffie and Ralph Merkle in the 1970s. Their groundbreaking Diffie-Hellman key exchange method allowed secure communication over insecure channels, laying the foundation for modern encryption protocols. Hellman has also contributed to cybersecurity policy and ethical discussions on nuclear risk. His work has The post Turing Award Special: A Conversation with Martin Hellman appeared first on Software Engineering Daily.
The fallback for law enforcement agencies has always been the place where files are stored, and all the best encryption within end-to-end communications will not stop unencrypted files at rest from being examined. But when the user encrypts data into the Cloud and where they hold their own keys, that's when the nightmare begins for them. The rise of cybersecurity on the Internet Let's pinpoint the start of cybersecurity on the Internet to the 1970s. This saw the rise of the Lucifer cipher and saw banks properly protect their communications. This led to the 56-bit DES encryption method, and which led many to suspect that the size of the key had been crippled due to the demands of law enforcement agencies. But, there was an even greater threat to these agencies evolving: public key encryption. The rise of public key encryption started in the mid-1970s when Whitfield Diffie and Marty Hellman first defined a method that allowed us to secure our communications using a key exchange method — the Diffie-Hellman key exchange method. And then, almost a year later, Rivest, Shamir and Adleman presented a way to digitally sign a hash of data with the RSA signature method, and where a server could sign a hash of data with its private key and for this to be verified with an associated public key. For almost the first time, we could digitally verify that we were connecting to a valid system. But, the RSA method could not only sign data, it could also encrypt things with a public key, and where the private key could now be used to decrypt the data. It was a nightmare come true for law enforcement agencies. What was magical about these methods was that you could encrypt data with keys that could be created for every single session — and generated and stored on user devices. User devices could even pick the keys that they wanted and their sizes and security levels. The days of security being crippled were fading fast. While the first versions of SSL were crippled by the demands for limits on this security, eventually, SSL evolved into something that could not be controlled. But, still files could still be viewed on user devices, so it was not a major problem for investigators. Then, in 2001, the AES method was standardized by NIST, along with the newly defined SHA-256 hashing method, and we basically had all the security methods in place. But all of this did not please law enforcement agencies. For them, the rise of cryptography removed the opportunities that they had had in the past and where they could mass harvest information from phone calls or from the postal service. For the first time in history, citizens were free from spying from both those who protect nations and those who attack citizens. The Wild West years of the early Internet — and where little could be trusted — have subsided, and now we have systems which take encryption from one service on a device to another service on another device — end-to-end encryption. End-to-end encryption For some, end-to-end encryption was the final nail in the coffin for those who wish to monitor the tracks of citizens. This is data in motion, and where law enforcement agencies could still peak at data at rest and where the data is actually stored. Once data in motion and data at rest were encrypted, the door was effectively closed for peaking at data. And, so, companies such as Apple advanced new methods which protected data at rest, and where all of a citizen's data could be encrypted onto the Cloud without Apple having the encryption key to view any part of it. For this, they created the Advanced Data Protection service: This service protects things like citizens' photos, iCloud Drive, and wallet passes. For almost the first time, we had almost perfect security — and where five decades of advancement were finally coming together. We now have end-to-end encryption in apps such as What's App and Signal, and Apple provides secure data storage. But, some governments around the world saw the rise of privacy as a threat to their security agencies, and where the usage of encryption with file storage and over-the-air would mean that they could not monitor their citizens for threats against society. It is — and always will be — a lose-lose store on both sides. And, so, many governments have been calling for a back door in cryptography so that a “good guy” could get access to the citizen data and communication, but not a “bad guy”. Unfortunately, that's not the way that encryption works, and where backdoors are a bad thing and difficult to hide. So, the UK government has put pressure on Apple to provide them with a backdoor into their secure systems. For this, Apple would have to either provide them with a magic key to open up encrypted communications and file store, or dump their Advanced Data Protection system, and leave files unencrypted for investigation. Apple stepping back It would have been a difficult choice for Apple, but they have decided to drop their Advanced Data Protection system for UK users, and not go with the nightmare of a backdoor in their systems. Imagine if a terrorist had stored their files in iCloud, and law enforcement agencies had requested these files. Well, Apple would have to hold their hands up and say that they didn't have the encryption files to access them, as the encryption keys were held by the user. I trust Apple and believe they have some of the best security around. When was the last time you heard of someone getting some malware on an Apple system? They support a proper secure enclave and are advancing a privacy-aware cloud infrastructure for machine learning. They have also brought forward homomorphic encryption applications. Of all the big tech companies, Apple leads the way in terms of supporting the privacy and the security of users. Conclusions I feel sorry for Apple, as they have been painted into a corner. From a cybersecurity point-of-view, it is disappointing that Apple has been forced to step back on the Advanced Data Protection tool, as it was a great advancement in overcoming large-scale data breaches. And, like it or not, there is no magic wand that stops a bad actor from using something that a good actor has access to. Basically, if you leave your front door key under the mat, you have no guarantee that someone else will find the key and use it. We have advanced cybersecurity for the past few decades and now use end-to-end encryption in a way we should have done from the start of the Internet. Of course, there are no winners in this, and society must find ways to protect itself from bad people, but opening up the whole of iCloud seems like a disaster waiting to happen. The door is open for other more agile companies to support enhanced security and privacy, as the large tech companies seem to be applying the brake on some of their security advancements.
Clifford Cocks is a British mathematician and cryptographer. While working at GCHQ, he invented public key encryption, and which predates the work of the RSA and Diffie-Hellman methods. He studied mathematics as an undergraduate at Kings College, Cambridge, and then joined the Communications-Electronics Security Group (CESG) at GCHQ in 1973. After his discovery of a usable public key encryption method, he went on to create one of the first Identity-Based Encryption methods and which is based on quadratic residues rather than bilinear pairings. In 2008, he was made a Companion of the Order of the Bath (CB). Then, in 2010, he and James Ellis and Malcolm Williamson were honoured by the IEEE for their part in the development of public key encryption. In 2015, he was elected as a Fellow of the Royal Society, and, in the same year, he received an honorary PhD from the University of Birmingham. Then, in 2021, Clifford was inducted into the Cryptologic Hall of Honour. Read more: https://medium.com/asecuritysite-when-bob-met-alice/so-who-invented-public-key-encryption-213ceef7759
This week, in my lecture, I will outline one of the most amazing methods ever created in computer science: the Diffie-Hellman method. It was first outlined by Whitfield Diffie and Marty Hellman in 1976 in a paper that built the foundation of our modern world of cybersecurity. https://billatnapier.medium.com/after-48-years-its-a-long-goodbye-to-the-diffie-hellman-method-a6976a562bfe
This time on PING, Peter Thomassen from deSEC and Jason Goertzen from Sandbox AQ discuss their research project on post quantum cryptography in DNSSEC, funded by NLNet Labs. Post Quantum cryptography is a response to the risk that a future quantum computer will be able to implement Shor's Algorithm -a mechanism to uncover the private key in the RSA public-private key cryptographic mechanism, as well as Diffie-Hellman and Elliptic Curve methods. This would render all existing public-private based security useless, because with knowledge of the private key by a third party, the ability to sign uniquely over things is lost: DNSSEC doesn't depend on secrecy of messages but it does depend on RSA and elliptic curve signatures. We'd lose trust in the DNSSEC protections the private key provides. Post Quantum Cryptography (PQC) addresses this by implementing methods which are not exposed to the weakness that Shor's Algorithm can exploit. But, the cost and complexity of these PQC methods rises. Peter and Jason have been exploring implementations of some of the NIST candidate post quantum algorithms, deployed into bind9 and PowerDNS code. They've been able to use the Atlas system to test how reliably the signed contents can be seen in the DNS and have confirmed that some aspects of packet size in the DNS, and new algorithms will be a problem in deployment as things stand. As they note, it's too soon to move this work into IETF DNS standards process but there is a continuing interest in researching the space, with other activity underway from SIDN which we'll also feature on PING.
What do you know about cryptography? Have you ever wanted to get a better understanding of some of the maths behind encryption? This week we speak to Ed, a Senior Technologist at PI, about some of the history and basics of encryption. Find out more about encryption: - Computerphile on youtube (https://www.youtube.com/@Computerphile) is a computer science professor with a range of useful and accessible videos on encryption - Cloudflare have a helpful learning centre including this article on how encryption works and why cloudflare use Lava lamps to generate keys: https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/ - This is a helpful article on Diffie-Hellman including a diagram of the colours demonstration, which Ed discusses during the podcast: https://www.comparitech.com/blog/information-security/diffie-hellman-key-exchange/ - This article is great for learning more about hashing: https://auth0.com/blog/hashing-in-action-understanding-bcrypt/ - And if you're interested here is the wikipedia page on the Skytale sticks Ed talks about (https://en.wikipedia.org/wiki/Scytale) Learn more about PI's work on encryption: - PI's main encryption learn page: https://privacyinternational.org/learn/encryption - A PI report on the importance of End to End Encryption (E2EE): https://privacyinternational.org/report/4949/securing-privacy-end-end-encryption
This seminar series runs for students on the Applied Cryptography and Trust module, but invites guests from students from across the university. Martin is one of the co-creators of public key encryption, and worked alongside Whitfield Diffie in the creation of the widely used Diffie-Hellman method. In 2015, he was presented with the ACM Turing Award (the equivalent of a Nobel Prize in Computer Science) for his contribution to computer science. He is currently a professor emeritus at Stanford University. https://engineering.stanford.edu/node/9141/printable/print https://ee.stanford.edu/~hellman/
Whitfield Diffie is one of the greatest Computer Scientists ever. He - along with Marty Hellman - was one of the first to propose the usage of public key encryption and co-created the Diffie-Hellman (DH) key exchange method. Overall, the Diffie-Hellman method is still used in virtually every Web connection on the Internet, and has changed from using discrete log methods to elliptic curve methods. In 2015, Whitfield was also awarded the ACM Turing Prize - and which is the Nobel Prize equivalent in Computer Science. In this on-line talk he meets with Edinburgh Napier University students, but the chat is open to anyone who would like to listen to Whitfield.
Quantum computers will change and even break the cryptography we have today. To defeat a "Harvest Now, Decrypt Later" strategy by bad actors (even nation states), Denis Mandich, CTO and co-founder of Qrypt, is proposing a type of crypto agility that compiles the keys on your laptop instead of distributing them across the internet. He also talks about how you won't need a quantum computer in your home; you'll be able to access one in the cloud the way you can access AWS today.
Alex Lawrence, Field CISO at Sysdig, joins Corey on Screaming in the Cloud to discuss how he went from studying bioluminescence and mycology to working in tech, and his stance on why open source is the future of cloud security. Alex draws an interesting parallel between the creative culture at companies like Pixar and the iterative and collaborative culture of open-source software development, and explains why iteration speed is crucial in cloud security. Corey and Alex also discuss the pros and cons of having so many specialized tools that tackle specific functions in cloud security, and the different postures companies take towards their cloud security practices. About AlexAlex Lawrence is a Field CISO at Sysdig. Alex has an extensive history working in the datacenter as well as with the world of DevOps. Prior to moving into a solutions role, Alex spent a majority of his time working in the world of OSS on identity, authentication, user management and security. Alex's educational background has nothing to do with his day-to-day career; however, if you'd like to have a spirited conversation on bioluminescence or fungus, he'd be happy to oblige.Links Referenced: Sysdig: https://sysdig.com/ sysdig.com/opensource: https://sysdig.com/opensource falco.org: https://falco.org TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends over at Sysdig, and they have brought to me Alexander Lawrence, who's a principal security architect over at Sysdig. Alexander, thank you for joining me.Alex: Hey, thanks for having me, Corey.Corey: So, we all have fascinating origin stories. Invariably you talk to someone, no one in tech emerged fully-formed from the forehead of some God. Most of us wound up starting off doing this as a hobby, late at night, sitting in the dark, rarely emerging. You, on the other hand, studied mycology, so watching the rest of us sit in the dark and growing mushrooms was basically how you started, is my understanding of your origin story. Accurate, not accurate at all, or something in between?Alex: Yeah, decently accurate. So, I was in school during the wonderful tech bubble burst, right, high school era, and I always told everybody, there's no way I'm going to go into technology. There's tons of people out there looking for a job. Why would I do that? And let's face it, everybody expected me to, so being an angsty teenager, I couldn't have that. So, I went into college looking into whatever I thought was interesting, and it turned out I had a predilection to go towards fungus and plants.Corey: Then you realized some of them glow and that wound up being too bright for you, so all right, we're done with this; time to move into tech?Alex: [laugh]. Strangely enough, my thesis, my capstone, was on the coevolution of bioluminescence across aquatic and terrestrial organisms. And so, did a lot of focused work on specifically bioluminescent fungus and bioluminescing fish, like Photoblepharon palpebratus and things like that.Corey: When I talk to people who are trying to figure out, okay, I don't like what's going on in my career, I want to do something different, and their assumption is, oh, I have to start over at square one. It's no, find the job that's halfway between what you're doing now and what you want to be doing, and make lateral moves rather than starting over five years in or whatnot. But I have to wonder, how on earth did you go from A to B in this context?Alex: Yeah, so I had always done tech. My first job really was in tech at the school districts that I went to in high school. And so, I went into college doing tech. I volunteered at the ELCA and other organizations doing tech, and so it basically funded my college career. And by the time I finished up through grad school, I realized my life was going to be writing papers so that other people could do the research that I was coming up with, and I thought that sounded like a pretty miserable life.And so, it became a hobby, and the thing I had done throughout my entire college career was technology, and so that became my new career and vocation. So, I was kind of doing both, and then ended up landing in tech for the job market.Corey: And you've effectively moved through the industry to the point where you're now in security architecture over at Sysdig, which, when I first saw Sysdig launch many years ago, it was, this is an interesting tool. I can see observability stories, I can see understanding what's going on at a deep level. I liked it as a learning tool, frankly. And it makes sense, with the benefit of hindsight, that oh, yeah, I suppose it does make some sense that there are security implications thereof. But one of the things that you've said that I really want to dig into that I'm honestly in full support of because it'll irritate just the absolute worst kinds of people is—one of the core beliefs that you espouse is that security when it comes to cloud is inherently open-source-based or at least derived. I don't want to misstate your position on this. How do you view it?Alex: Yeah. Yeah, so basically, the stance I have here is that the future of security in cloud is open-source. And the reason I say that is that it's a bunch of open standards that have basically produced a lot of the technologies that we're using in that stack, right, your web servers, your automation tooling, all of your different components are built on open stacks, and people are looking to other open tools to augment those things. And the reality is, is that the security environment that we're in is changing drastically in the cloud as opposed to what it was like in the on-premises world. On-prem was great—it still is great; a lot of folks still use it and thrive on it—but as we look at the way software is built and the way we interface with infrastructure, the cloud has changed that dramatically.Basically, things are a lot faster than they used to be. The model we have to use in order to make sure our security is good has dramatically changed, right, and all that comes down to speed and how quickly things evolve. I tend to take a position that one single brain—one entity, so to speak—can't keep up with that rapid evolution of things. Like, a good example is Log4j, right? When Log4j hit this last year, that was a pretty broad attack that affected a lot of people. You saw open tooling out there, like Falco and others, they had a policy to detect and help triage that within a couple of hours of it hitting the internet. Other proprietary tooling, it took much longer than two hours.Corey: Part of me wonders what the root cause behind that delay is because it's not that the engineers working at these companies are somehow worse than folks in the open communities. In some cases, they're the same people. It feels like it's almost corporate process ossification of, “Okay, we built a thing. Now, we need to make sure it goes through branding and legal and marketing and we need to bring in 16 other teams to make this work.” Whereas in the open-source world, it feels like there's much more of a, “I push the deploy button and it's up. The end.” There is no step two.Alex: [laugh]. Yeah, so there is certainly a certain element of that. And I think it's just the way different paradigms work. There's a fantastic book out there called Creativity, Inc., and it's basically a book about how Pixar manages itself, right? How do they deal with creating movies? How do they deal with doing what they do, well?And really, what it comes down to is fostering a culture of creativity. And that typically revolves around being able to fail fast, take risks, see if it sticks, see if it works. And it's not that corporate entities don't do that. They certainly do, but again, if you think about the way the open-source world works, people are submitting, you know, PRs, pull requests, they're putting out different solutions, different fixes to problems, and the ones that end up solving it the best are often the ones that end up coming to the top, right? And so, it's just—the way you iterate is much more akin to that kind of creativity-based mindset that I think you get out of traditional organizations and corporations.Corey: There's also, I think—I don't know if this is necessarily the exact point, but it feels like it's at least aligned with it—where there was for a long time—by which I mean, pretty much 40 years at this point—a debate between open disclosure and telling people of things that you have found in vendors products versus closed disclosure; you only wind—or whatever the term is where you tell the vendor, give them time to fix it, and it gets out the door. But we've seen again and again and again, where researchers find something, report it, and then it sits there, in some cases for years, but then when it goes public and the company looks bad as a result, they scramble to fix it. I wish it were not this way, but it seems that in some cases, public shaming is the only thing that works to get companies to secure their stuff.Alex: Yeah, and I don't know if it's public shaming, per se, that does it, or it's just priorities, or it's just, you know, however it might go, there's always been this notion of, “Okay, we found a breach. Let's disclose appropriately, you know, between two entities, give time to remediate.” Because there is a potential risk that if you disclose publicly that it can be abused and used in very malicious ways—and we certainly don't want that—but there also is a certain level of onus once the disclosure happens privately that we got to go and take care of those things. And so, it's a balancing act.I don't know what the right solution is. I mean, if I did, I think everybody would benefit from things like that, but we just don't know the proper answer. The workflow is complex, it is difficult, and I think doing our due diligence to make sure that we disclose appropriately is the right path to go down. When we get those disclosures we need to take them seriously is when it comes down to.Corey: What I find interesting is your premise that the future of cloud security is open-source. Like, I could make a strong argument that today, we definitely have an open-source culture around cloud security and need to, but you're talking about that shifting along the fourth dimension. What's the change? What do you see evolving?Alex: Yeah, I think for me, it's about the collaboration. I think there are segments of industries that communicate with each other very, very well, and I think there's others who do a decent job, you know, behind closed doors, and I think there's others, again, that don't communicate at all. So, all of my background predominantly has been in higher-ed, K-12, academia, and I find that a lot of those organizations do an extremely good job of partnering together, working together to move towards, kind of, a greater good, a greater goal. An example of that would be a group out in the Pacific Northwest called NWACC—the NorthWest Academic Computing Consortium. And so, it's every university in the Northwest all come together to have CIO Summits, to have Security Summits, to trade knowledge, to work together, basically, to have a better overall security posture.And they do it pretty much out in the open and collaborating with each other, even though they are also direct competitors, right? They all want the same students. It's a little bit of a different way of thinking, and they've been doing it for years. And I'm finding that to be a trend that's happening more and more outside of just academia. And so, when I say the future is open, if you think about the tooling academia typically uses, it is very open-source-oriented, it is very collaborative.There's no specifications on things like eduPerson to be able to go and define what a user looks like. There's things like, you know, CAS and Shibboleth to do account authorization and things like that. They all collaborate on tooling in that regard. We're seeing more of that in the commercial space as well. And so, when I say the future of security in cloud is open-source, it's models like this that I think are becoming more and more effective, right?It's not just the larger entities talking to each other. It's everybody talking with each other, everybody collaborating with each other, and having an overall better security posture. The reality is, is that the folks we're defending ourselves against, they already are communicating, they already are using that model to work together to take down who they view as their targets: us, right? We need to do the same to be able to keep up. We need to be able to have those conversations openly, work together openly, and be able to set that security posture across that kind of overall space.Corey: There's definitely a concern that if okay, you have all these companies and community collaborating around security aspects in public, that well won't the bad actors be able to see what they're looking at and how they're approaching it and, in some cases, move faster than they can or, in other cases, effectively wind up polluting the conversation by claiming to be good actors when they're not. And there's so many different ways that this can manifest. It feels like fear is always the thing that stops people from going down this path, but there is some instance of validity to that I would imagine.Alex: Yeah, no. And I think that certainly is true, right? People are afraid to let go of, quote-unquote, “The keys to their kingdom,” their security posture, their things like that. And it makes sense, right? There's certain things that you would want to not necessarily talk about openly, like, specifically, you know, what Diffie–Hellman key exchange you're using or something like that, but there are ways to have these conversations about risks and posture and tooling and, you know, ways you approach it that help everybody else out, right?If someone finds a particularly novel way to do a detection with some sort of piece of tooling, they probably should be sharing that, right? Let's not keep it to ourselves. Traditionally, just because you know the tool doesn't necessarily mean that you're going to have a way in. Certainly, you know, it can give you a path or a vector to go after, but if we can at least have open standards about how we implement and how we can go about some of these different concepts, we can all gain from that, so to speak.Corey: Part of me wonders if the existing things that the large companies are collaborating on lead to a culture that specifically pushes back against this. A classic example from my misspent youth is that an awful lot of the anti-abuse departments at these large companies are in constant communication. Because if you work at Microsoft, or Google or Amazon, your adversary, as you see it, in the Trust and Safety Group is not those other companies. It's bad actors attempting to commit fraud. So, when you start seeing particular bad actors emerging from certain parts of the network, sharing that makes everything better because there's an understanding there that it's not, “Oh, Microsoft has bad security this week,” or, “Google will wind up approving fraudulent accounts that start spamming everyone.”Because the takeaway by theby the customers is not that this one company is bad; it's oh, the cloud isn't safe. We shouldn't use cloud. And that leads to worse outcomes for basically everyone. But they're als—one of the most carefully guarded secrets at all these companies is how they do fraud prevention and spam detection because if adversaries find that out, working around them becomes a heck of a lot easier. I don't know, for example, how AWS determines whether a massive account overage in a free-tier account is considered to be a bad actor or someone who made a legitimate mistake. I can guess, but the actual signal that they use is something that they would never in a million years tell me. They probably won't even tell each other specifics of that.Alex: Certainly, and I'm not advocating that they let all of the details out, per se, but I think it would be good to be able to have more of an open posture in terms of, like, you know what tooling do they use? How do they accomplish that feat? Like, are they looking at a particular metric? How do they basically handle that posture going forward? Like, what can I do to replicate a similar concept?I don't need to know all the details, but would be nice if they embrace, you know, open tooling, like say a Trivy or a Falco or whatever the thing is, right, they're using to do this process and then contribute back to that project to make it better for everybody. When you kind of keep that stuff closed-source, that's when you start running into that issue where, you know, they have that, quote-unquote, “Advantage,” that other folks aren't getting. Maybe there's something we can do better in the community, and if we can all be better, it's better for everybody.Corey: There's a constant customer pain in the fact that every cloud provider, for example, has its own security perspective—the way that identity is managed, the way that security boundaries exist, the way that telemetry from these things winds up getting represented—where a number of companies that are looking at doing things that have to work across cloud for a variety of reasons—some good, some not so good—have decided that, okay, we're just going to basically treat all these providers as, more or less, dumb pipes and dumb infrastructure. Great, we're just going to run Kubernetes on all these things, and then once it's inside of our cluster, then we'll build our own security overlay around all of these things. They shouldn't have to do that. There should be a unified set of approaches to these things. At least, I wish there were.Alex: Yeah, and I think that's where you see a lot of the open standards evolving. A lot of the different CNCF projects out there are basically built on that concept. Like, okay, we've got Kubernetes. We've got a particular pipeline, we've got a particular type of implementation of a security measure or whatever it might be. And so, there's a lot of projects built around how do we standardize those things and make them work cross-functionally, regardless of where they're running.It's actually one of the things I quite like about Kubernetes: it makes it be a little more abstract for the developers or the infrastructure folks. At one point in time, you had your on-premises stuff and you built your stuff towards how your on-prem looked. Then you went to the cloud and started building yourself to look like what that cloud look like. And then another cloud showed up and you had to go use that one. Got to go refactor your application to now work in that cloud.Kubernetes has basically become, like, this gigantic API ball to interface with the clouds, and you don't have to build an application four different ways anymore. You can build it one way and it can work on-prem, it can work in Google, Azure, IBM, Oracle, you know, whoever, Amazon, whatever it needs to be. And then that also enables us to have a standard set of tools. So, we can use things like, you know, Rego or we can use things like Falco or we can use things that allow us to build tooling to secure those things the same way everywhere we go. And the benefit of most of those tools is that they're also configured, you know, via some level of codification, and so we can have a repository that contains our posture: apply that posture to that cluster, apply it to the other cluster in the other environment. It allows us to automate these things, go quicker, build the posture at the very beginning, along with that application.Corey: One of the problems I feel as a customer is that so many of these companies have a model for interacting with security issues that's frankly obnoxious. I am exhausted by the amount of chest-thumping, you'll see on keynote stages, all of the theme, “We're the best at security.” And whenever a vulnerability researcher reports something of a wide variety of different levels of severity, it always feels like the first concern from the company is not fix the issue, but rather, control the messaging around it.Whenever there's an issue, it's very clear that they will lean on people to rephrase things, not use certain words. It's, I don't know if the words used to describe this cross-tenant vulnerability are the biggest problem you should be focusing on right now. Yes, I understand that you can walk and chew gum at the same time as a big company, but it almost feels like the researchers are first screaming into a void, and then they're finally getting attention, but from all the people they don't want to get the attention from. It feels like this is not a welcoming environment for folks to report these things in good faith.Alex: [sigh]. Yeah, it's not. And I don't know what the solution is to that particular problem. I have opinions about why that exists. I won't go into those here, but it's cumbersome. It's difficult. I don't envy a lot of those research organizations.They're fantastic people coming up with great findings, they find really interesting stuff that comes out, but when you have to report and do that due diligence, that portion is not that fun. And then doing, you know, the fallout component, right: okay, now we have this thing we have to report, we have to go do something to fix it, you're right. I mean, people do often get really spun up on the verbiage or the implications and not just go fix the problem. And so again, if you have ways to mitigate that are more standards-based, that aren't specific to a particular cloud, like, you can use an open-source tool to mitigate, that can be quite the advantage.Corey: One of the challenges that I see across a wide swath of tooling and approaches to it have been that when I was trying to get some stuff to analyze CloudTrail logs in my own environment, I was really facing a bimodal distribution of options. On one end of the spectrum, it's a bunch of crappy stuff—or good stuff; hard to say—but it's all coming off of GitHub, open-source, build it yourself, et cetera. Good luck. And that's okay, awesome, but there's business value here and I'm thrilled to pay experts to make this problem go away.The other end of the spectrum is commercial security tooling, and it is almost impossible in my experience to find anything that costs less than $1,000 a month to start providing insight from a security perspective. Now, I understand the market forces that drive this. Truly I do, and I'm sympathetic to them. It is just as easy to sell $50,000 worth of software as it is five to an awful lot of companies, so yeah, go where the money is. But it also means that the small end of the market as hobbyists, as startups are just getting started, there is a price barrier to engaging in the quote-unquote, “Proper way,” to do security.So, the posture suffers. We'll bolt security on later when it becomes important is the philosophy, and we've all seen how well that plays out in the fullness of time. How do you square that circle? I think the answer has to be open-source improving to the point where it's not just random scripts, but renowned projects.Alex: Correct, yeah, and I'd agree with that. And so, we're kind of in this interesting phase. So, if you think about, like, raw Linux applications, right, Linux, always is the tenant that you build an application to do one thing, does that one thing really, really, really well. And then you ended up with this thing called, like, you know, the Cacti monitoring stack. And so, you ended up having, like, 600 tools you strung together to get this one monitoring function done.We're kind of in a similar spot in a lot of ways right now, in the open-source security world where, like, if you want to do scanning, you can do, like, Clair or you can do Trivy or you have a couple different choices, right? If you want to do posture, you've got things like Qbench that are out there. If you want to go do runtime security stuff, you've got something like Falco. So, you've got all these tools to string together, right, to give you all of these different components. And if you want, you can build it yourself, and you can run it yourself and it can be very fun and effective.But at some point in your life, you probably don't want to be care-and-feeding your child that you built, right? It's 18 years later now, and you want to go back to having your life, and so you end up buying a tool, right? That's why Gartner made this whole CNAP category, right? It's this humongous category of products that are putting all of these different components together into one gigantic package. And the whole goal there is just to make lives a little bit easier because running all the tools yourself, it's fun, I love it, I did it myself for a long time, but eventually, you know, you want to try to work on some other stuff, too.Corey: At one point, I wound up running the numbers of all of the first-party security offerings that AWS offered, and for most use cases of significant scale, the cost for those security services was more than the cost of the theoretical breach that they'd be guarding against. And I think that there's a very dangerous incentive that arises when you start turning security observability into your own platform as a profit center. Because it's, well, we could make a lot of money if we don't actually fix the root issue and just sell tools to address and mitigate some of it—not that I think that's the intentional direction that these companies are taking these things and I don't want to ascribe malice to them, but you can feel that start to be the trend that some decisions get pushed in.Alex: Yeah, I mean, everything comes down to data, right? It has to be stored somewhere, processed somewhere, analyzed somewhere. That always has a cost with it. And so, that's always this notion of the shared security model, right? We have to have someone have ownership over that data, and most of the time, that's the end-user, right? It's their data, it's their responsibility.And so, these offerings become things that they have that you can tie into to work within the ecosystem, work within their infrastructure to get that value out of your data, right? You know, where is the security model going? Where do I have issues? Where do I have misconfigurations? But again, someone has to pay for that processing time. And so, that ends up having a pretty extreme cost to it.And so, it ends up being a hard problem to solve. And it gets even harder if you're multi-cloud, right? You can't necessarily use the tooling of AWS inside of Azure or inside of Google. And other products are trying to do that, right? They're trying to be able to let you integrate their security center with other clouds as well.And it's kind of created this really interesting dichotomy where you almost have frenemies, right, where you've got, you know, a big Azure customer who's also a big AWS customer. Well, they want to go use Defender on all of their infrastructure, and Microsoft is trying to do their best to allow you to do that. Conversely, not all clouds operate in that same capacity. And you're correct, they all come at extremely different costs, they have different price models, they have different ways of going about it. And it becomes really difficult to figure out what is the best path forward.Generally, my stance is anything is better than nothing, right? So, if your only choice is using Defender to do all your stuff and it cost you an arm or leg, unfortunate, but great; at least you got something. If the path is, you know, go use this random open-source thing, great. Go do that. Early on, when I'd been at—was at Sysdig about five years ago, my big message was, you know, I don't care what you do. At least scan your containers. If you're doing nothing else in life, use Clair; scan the darn things. Don't do nothing.That's not really a problem these days, thankfully, but now we're more to a world where it's like, well, okay, you've got your containers, you've got your applications running in production. You've scanned them, that's great, but you're doing nothing at runtime. You're doing nothing in your posture world, right? Do something about it. So, maybe that is buy the enterprise tool from the cloud you're working in, buy it from some other vendor, use the open-source tool, do something.Thankfully, we live in a world where there are plenty of open tools out there we can adopt and leverage. You used the example of CloudTrail earlier. I don't know if you saw it, but there was a really, really cool talk at SharkFest last year from Gerald Combs where they leveraged Wireshark to be able to read CloudTrail logs. Which I thought was awesome.Corey: That feels more than a little bit ridiculous, just because it's—I mean I guess you could extract the JSON object across the wire then reassemble it. But, yeah, I need to think on that one.Alex: Yeah. So, it's actually really cool. They took the plugins from Falco that exist and they rewired Wireshark to leverage those plugins to read the JSON data from the CloudTrail and then wired it into the Wireshark interface to be able to do a visual inspect of CloudTrail logs. So, just like you could do, like, a follow this IP with a PCAP, you could do the same concept inside of your cloud log. So, if you look up Logray, you'll find it on the internet out there. You'll see demos of Gerald showing it off. It was a pretty darn cool way to use a visualization, let's be honest, most security professionals already know how to use in a more modern infrastructure.Corey: One last topic that I want to go into with you before we call this an episode is something that's been bugging me more and more over the years—and it annoyed me a lot when I had to deal with this stuff as a SOC 2 control owner and it's gotten exponentially worse every time I've had to deal with it ever since—and that is the seeming view of compliance and security as being one and the same, to the point where in one of my accounts that I secured rather well, I thought, I installed security hub and finally jumped through all those hoops and paid the taxes and the rest and then waited 24 hours to gather some data, then 24 hours to gather more. Awesome. Applied the AWS-approved a foundational security benchmark to it and it started shrieking its bloody head off about all of the things that were insecure and not configured properly. One of them, okay, great, it complained that the ‘Block all S3 Public Access' setting was not turned on for the account. So, I turned that on. Great.Now, it's still complaining that I have not gone through and also enabled the ‘Block Public Access Setting' on each and every S3 bucket within it. That is not improving your security posture in any meaningful way. That is box-checking so that someone in a compliance role can check that off and move on to the next thing on the clipboard. Now, originally, they started off being good-intentioned, but the result is I'm besieged by these things that don't actually matter and that means I'm not going to have time to focus on the things that actually do. Please tell me I'm wrong on some of this.Alex: [laugh].Corey: I really need to hear that.Alex: I can't. Unfortunately, I agree with you that a lot of that seems erroneous. But let's be honest, auditors have a job for a reason.Corey: Oh, I'm not besmirching the role of the auditor. Far from it. The problem I run into is that it's the Human Nessus report that dumps out, “Here's the 700 things to go fix in your environment,” as opposed to, “Here's the five things you can do right now that will meaningfully improve your security posture.”Alex: Yeah. And so, I think that's a place we see a lot of vendors moving, and I think that is the right path forward. Because we are in a world where we generate reports that are miles and miles long, we throw them over a wall to somebody, and that person says, “Are you crazy?” Like, “You want me to go do what with my time?” Like, “No. I can't. No. This is way too much.”And so, if we can narrow these things down to what matters the most today, and then what can we get rid of tomorrow, that makes life better for everybody. There are certainly ways to accomplish that across a lot of different dimensions, be that vulnerability management, or configuration management stuff, runtime stuff, and that is certainly the way we should approach it. Unfortunately, not all frameworks allow us to look at it that way.Corey: I mean, even AWS's thing here is yelling at me for a number of services not having encryption-at-rest turned on, like CloudTrail logs, or SNS topics. It's okay, let's be very clear what that is defending against: someone stealing drives out of a data center and taking them off to view the data. Is that something that I need to worry about in a public cloud provider context? Not unless I'm the CIA or something pretty close to that. I mean, if you can get my data out of an AWS data center and survive, congratulations, I kind of feel like you've earned it at this point. But that obscures things I need to be doing that I'm not.Alex: Back in the day, I had a customer who used to have—they had storage arrays and their storage arrays' logins were the default login that they came with the array. They never changed it. You just logged in with admin and no password. And I was like, “You know, you should probably fix that.” And he sent a message back saying, “Yeah, you know, maybe I should, but my feeling is that if it got that far into my infrastructure where they can get to that interface, I'm already screwed, so it doesn't really matter to me if I set that admin password or not.”Corey: Yeah, there is a defense-in-depth argument to be made. I am not disputing that, but the Cisco world is melting down right now because of a bunch of very severe vulnerabilities that have been disclosed. But everything to exploit these things always requires, well you need access to the management interface. Back when I was a network administrator at Chapman University in 2006, even then, I knew, “Well, we certainly don't want to put the management interfaces on the same VLAN that's passing traffic.”So, is it good that there's an unpatched vulnerability there? No, but Shodan, the security vulnerability search engine shows over 80,000 instances that are affected on the public internet. It would never have occurred to me to put the management interface of important network gear on the public internet. That just is… I don't understand that.Alex: Yeah.Corey: So, on some level, I think the lesson here is that there's always someone who has something else to focus on at a given moment, and… where it's a spectrum: no one is fully secure, but ideally, you don't want to be the lowest of low-hanging fruit.Alex: Right, right. I mean, if you were fully secure, you'd just turn it off, but unfortunately, we can't do that. We have to have it be accessible because that's our jobs. And so, if we're having it be accessible, we got to do the best we can. And I think that is a good point, right? Not being the worst should be your goal, at the very, very least.Doing bare minimums, looking at those checks, deciding if they're relevant for you or not, just because it says the configuration is required, you know, is it required in your use case? Is it required for your requirements? Like, you know, are you a FedRAMP customer? Okay, yeah, it's probably a requirement because, you know, it's FedRAMP. They're going to tell you got to do it. But is it your dev environment? Is it your demo stuff? You know, where does it exist, right? There's certain areas where it makes sense to deal with it and certain areas where it makes sense to take care of it.Corey: I really want to thank you for taking the time to talk me through your thoughts on all this. If people want to learn more, where's the best place for them to find you?Alex: Yeah, so they can either go to sysdig.com/opensource. A bunch of open-source resources there. They can go to falco.org, read about the stuff on that site, as well. Lots of different ways to kind of go and get yourself educated on stuff in this space.Corey: And we will, of course, put links to that into the show notes. Thank you so much for being so generous with your time. I appreciate it.Alex: Yeah, thanks for having me. I appreciate it.Corey: Alexander Lawrence, principal security architect at Sysdig. I'm Cloud Economist Corey Quinn, and this episode has been brought to us by our friends, also at Sysdig. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that I will then read later when I pick it off the wire using Wireshark.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
Here are my 100 interesting things to learn about cryptography: For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)] For a 256-bit encryption key, there are 115,792 billion billion billion billion billion billion billion billion possible keys. [Calc: 2**256/(1e9**8)] To crack a 128-bit encryption with brute force using a cracker running at 1 Teracracks/second, will take — on average — 5 million million million years to crack. Tera is 1,000 billion. [Calc: 2**128/100e9/2/60/60/24/365/(1e6**3)] For a 256-bit key this is 1,835 million million million million million million million million million years. For the brute force cracking of a 35-bit key symmetric key (such as AES), you only need to pay for the boiling of a teaspoon of energy. For a 50-bit key, you just need to have enough money to pay to boil the water for a shower. For a 90-bit symmetric key, you would need the energy to boil a sea, and for a 105-bit symmetric key, you need the energy to boil and ocean. For a 128-bit key, there just isn't enough water on the planet to boil for that. Ref: here. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force. One of the first symmetric key encryption methods was the LUCIFER cipher and was created by Horst Feistel at IBM. It was further developed into the DES encryption method. Many, at the time of the adoption of DES, felt that its 56-bit key was too small to be secure and that the NSA had a role in limiting them. With a block cipher, we only have to deal with a fixed size of blocks. DES and 3DES use a 64-bit (eight-byte) block size, and AES uses a 128-bit block size (16 bytes). With symmetric key methods, we either have block ciphers, such as DES, AES CBC and AES ECB, or stream ciphers, such as ChaCha20 and RC4. In order to enhance security, AES has a number of rounds where parts of the key are applied. With 128-bit AES we have 10 rounds, and 14 rounds for 256-bit AES. In AES, we use an S-box to scramble the bytes, and which is applied for each round. When decrypting, we have the inverse of the S-box used in the encrypting process. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel. With the Diffie-Hellman method. Bob creates x and shares g^x (mod p), and Alice creates y, and shares g^y (mod p). The shared key is g^{xy} (mod p). Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). Adi Shamir defines a secret share method, and which defines a mathematical equation with the sharing of (x,y), and where a constant value in the equation is the secret. With Shamir Secret Shares (SSS), for a quadratic equation of y=x²+5x+6, the secret is 6. We can share three points at x=1, x=2 and y=3, and which gives y=12, y=20, and y=20, respectively. With the points of (1,12), (2,20), and (3,20), we can recover the value of 6. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference. With secret shares, with the highest polynomial power of n, we need n+1 points to come together to regenerate the secret. For example, y=2x+5 needs two points to come together, while y=x²+15x+4 needs three points. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled “Cryptographic Communications System and Method”. In public key encryption, we use the public key to encrypt data and the private key to decrypt it. In digital signing, we use the private key to sign a hash and create a digital signature, and then the associated public key to verify the signature. Len Adleman — the “A” in the RSA method — thought that the RSA paper would be one of the least significant papers he would ever publish. The RSA method came to Ron Rivest while he slept on a couch. Martin Gardner published information on the RSA method in his Scientific American article. Initially, there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. The security of RSA is based on the multiplication of two random prime numbers (p and q) to give a public modulus (N). The difficulty of RSA is the difficulty in factorizing this modulus. Once factorized, it is easy to decrypt a ciphertext that has been encrypted using the related modulus. In RSA, we have a public key of (e,N) and a private key of (d,N). e is the public exponent and d is the private exponent. The public exponent is normally set at 65,537. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext in RSA. In RSA, the ciphertext is computed from a message of M as C=M^e (mod N), and is decrypted with M=C^d (mod N). We compute the the private exponent (d) from the inverse of the public exponent (e) modulus PHI, and where PHI is (p-1)*(q-1). If we can determine p and q, we can compute PHI. Anything below a 738-bit public modulus is relatively inexpensive to crack for RSA. To crack 2K RSA at the current time, we would need the energy to boil ever ocean on the planet to break it. RSA requires padding is required for security. A popular method has been PCKS#1v1.5 — but this is not provably secure and is susceptible to Bleichenbacher's attack. An improved method is Optimal Asymmetric Encryption Padding (OAEP) and was defined by Bellare and Rogaway and standardized in PKCS#1 v2. The main entity contained in a digital certificate is the public key of a named entity. This is either an RSA or an Elliptic Curve key. A digital certificate is signed with the private key of a trusted entity — Trent. The public key of Trent is then used to prove the integrity and trust of the associated public key. For an elliptic curve of y²=x³+ax+b (mod p), not every (x,y) point is possible. The total number of points is defined as the order (n). ECC (Elliptic Curve Cryptography) was invented by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A “04” in the public key is an uncompressed public key, and “02” and “03” are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve. The prime number used with secp256k1 is 2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a “02” if the y-co-ordinate is even; otherwise, it starts with a “03”. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, “Modular Multiplication without Trial Division.” Elliptic Curve methods use two basic operations: point address (P+Q) and point doubling (2.P). These can be combined to provide the scalar operation of a.G. In 1999, Don Johnson Alfred Menezes published a classic paper on “The Elliptic Curve Digital Signature Algorithm (ECDSA)”. It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US. ECDSA is a digital signature method and requires a random nonce value (k), and which should never be reused or repeated. ECDSA is an elliptic curve conversion of the DSA signature method. Digital signatures are defined in FIPS (Federal Information Processing Standard) 186–5. NIST approved the Rijndael method (led by Joan Daemen and Vincent Rijmen) for Advanced Encryption Standard (AES). Other contenders included Serpent (led by Ross Anderson), TwoFish (led by Bruce Schneier), MARS (led by IBM), and RC6 (led by Ron Rivest). ChaCha20 is a stream cipher that is based on Salsa20 and developed by Daniel J. Bernstein. MD5 has a 128-bit hash, SHA-1 has 160 bits and SHA-256 has 256-bits. It is relatively easy to create a hash collision with MD5. Google showed that it was possible to create a signature collision for a document with SHA-1. It is highly unlikely to get a hash collision for SHA-256. In 2015, NIST defined SHA-3 as a standard, and which was built on the Keccak hashing family — and which used a different method to SHA-2. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and standardized by NIST in August 2015 as SHA-3. Hash functions such as MD5, SHA-1 and SHA-256 have a fixed hash length, whereas an eXtendable-Output Function (XOF) produces a bit string that can be of any length. Examples are SHAKE128, SHAKE256, BLAKE2XB and BLAKE2XS. BLAKE 3 is the fastest cryptographically secure hashing method and was created by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn. Hashing methods can be slowed down with a number of rounds. These slower hashing methods include Bcrypt, PBKDF2 and scrypt. Argon 2 uses methods to try and break GPU cracking, such as using a given amount of memory and defining the CPU utlization. To speed up the operation of the SHA-3 hash, the team reduced the security of the method and reduce the number of rounds. The result is the 12 Kangaroo's hashing method. The number of rounds was reduced from 24 to 12 (with a security level of around 128 bits). Integrated Encryption Scheme (IES) is a hybrid encryption scheme which allows Alice to get Bob's public key and then generate an encryption key based on this public key, and she will use her private key to recover the symmetric. With ECIES, we use elliptic curve methods for the public key part. A MAC (Message Authentication Code) uses a symmetric key to sign a hash, and where Bob and Alice share the same secret key. The most popular method is HMAC (hash-based message authentication code). The AES block cipher can be converted into a stream cipher using modes such as GCM (Galois Counter Mode) and CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). A MAC is added to a symmetric key method in order to stop the ciphertext from being attacked by flipping bits. GCM does not have a MAC, and is thus susceptible to this attack. CCM is more secure, as it contains a MAC. With symmetric key encryption, we must remove the encryption keys in the reverse order they were applied. Commutative encryption overcomes this by allowing the keys to be removed in any order. It is estimated that Bitcoin miners consume 17.05 GW of electrical power per day and 149.46 TWh per year. A KDF (Key Derivation Function) is used to convert a passphrase or secret into an encryption key. The most popular methods are HKDF, PBKDF2 and Bcrypt. RSA, ECC and Discrete Log methods will all be cracked by quantum computers using Shor's algorithm Lattice methods represent bit values as polynomial values, such as 1001 is x³+1 as a polynomial. Taher Elgamal — the sole inventor of the ElGamal encryption method — and Paul Koche were the creators of SSL, and developed it for the Netscape browser. David Chaum is considered as a founder of electronic payments and, in 1983, created ECASH, along with publishing a paper on “Blind signatures for untraceable payments”. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, “We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.” In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, improved proof of work, and smart contracts. NI-ZKPs involves a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled “Non-interactive zero-knowledge and its applications”. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge). Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero. In 1992, David Chaum and Torben Pryds Pedersen published “Wallet databases with observers,” and outlined a method of shielding the details of a monetary transaction. In 1992, Adi Shamir (the “S” in RSA) published a paper on “How to share a secret” in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS). In 1991, Torbin P Pedersen published a paper entitled “Non-interactive and information-theoretic secure verifiable secret sharing” — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version and has better support for signature aggregation. It uses Twisted Edwards Curves. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as a “Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system”. The patent ran out in 2008. Curve 25519 uses the prime number of 2²⁵⁵-19 and was created by Daniel J. Bernstein. Peter Shor defined that elliptic curve methods can be broken with quantum computers. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name “bulletproofs” is defined as they are short, like a bullet, and with bulletproof security assumptions. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing-friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wires and transistors. This can be used to link a device to an NFT.
So, here's my Top 100 snippets of knowledge for blockchain: Blockchains use public key methods to integrate digital trust. Bob signs for a transaction with his private key, and Alice proves this with Bob's public key. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled “Cryptographic Communications System and Method”. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). David Chaum is considered as founders of electronic payments, and, in 1983, created ECASH, along with publishing a paper on “Blind signatures for untraceable payments”. Miners gather transactions on a regular basis, and these are added to a block and where each block has a Merkle hash. The first block on a blockchain does not have any previous blocks — and is named the genesis block. Blocks are bound in a chain, and where the previous, current and next block hashes are bound into the block. This makes the transactions in the block immutable. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Craig Steven Wright has claimed that he is Satoshi Nakamoto, but this claim has never been verified. Most blockchains use elliptic curve cryptography — a method which was created independently by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve. The prime number used with secp256k1 is ²²⁵⁶−²³²−²⁹−²⁸−²⁷−²⁶−²⁴−1. Satoshi published a 9-page paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” White Paper on 31 Oct 31, 2008. In 1997, Adam Black introduce the concept of Proof of Work of Hashcash in a paper entitled, “Hashcash — a denial of service countermeasure.” This work was used by Satoshi in his whitepaper. Satoshi focused on: a decentralized system, and a consensus model and addressed areas of double-spend, Sybil attacks and Eve-in-the-middle. The Sybil attack is where an adversary can take over the general consensus of a network — and leads to a 51% attack, and where the adversary manages to control 51% or more of the consensus infrastructure. Satoshi used UK spelling in his correspondence, such as using the spelling of “honour”. The first Bitcoin block was minted on 3 Jan 2009 and contained a message of “Chancellor on brink of second bailout for banks” (the headline from The Times, as published in London on that day). On 12 Jan 2009, Satoshi sent the first Bitcoin transaction of 50 BTC to Hal Finney [here]. A new block is created every 7–10 minutes on Bitcoin. In Aug 2023, the total Bitcoin blockchain size is 502 GB. As of Aug 2023, the top three cryptocurrencies are Bitcoin, Ether, and Tether. Bitcoin has a capitalization of $512 billion, Ether with $222 billion, and Tether at $83 billion. The total cryptocurrency capitalisation is $1.17 trillion. The original block size was 1MB for Bitcoin, but recently upgraded to support a 1.5MB block — and has around 3,000 transactions. Currently the block sizes are more than 1.7MB. Bitcoin uses a gossip protocol — named the Lightning Protocol — to propagate transactions. A Bitcoin wallet is created from a random seed value. This seed value is then used to create the 256-bit secp256k1 private key. A wallet seed can be converted into a mnemonic format using BIP39, and which uses 12 common words. This is a deterministic key, and which allows the regeneration of the original key in the correct form. BIP39 allows for the conversion of the key to a number of languages, including English, French and Italian. A private key in a wallet is stored in a Wif format, and which is a Base58 version of the 256-bit private key. The main source code for the Bitcoin blockchain is held at https://github.com/bitcoin, and is known as Bitcoin core. This is used to create nodes, store coins, and transactions with other nodes on the Bitcoin network. A 256-bit private key has 115,792 billion billion billion billion billion billion billion billion different keys. A public Bitcoin ID uses Base58 and has a limited character set of ‘123456789ABCDEFGHJKLMN PQRSTUVWXYZabcdefghijkmno pqrstuvwxyz', where we delete ‘0' (zero), ‘l' (lowercase ‘l'), and ‘I' (capital I) — as this can be interpreted as another character. In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a “02” if the y-co-ordinate is even, otherwise it starts with a “03”. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, “We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.” In Ethereum, the public key is used as the identity of a user (a.G), and is defined as a hexademical value. In Bitcoin, the public ID is created from a SHA256 hash of the public key, and then a RIPEMD160 of this, and then covered to Base58. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, “Modular Multiplication without Trial Division.” Elliptic Curve methods use two basic operations: point address (P+G) and point doubling (2.P). These can be combined to provide the scalar operation of a.G. In 1999, Don Johnson Alfred Menezes published a classic paper on “The Elliptic Curve Digital Signature Algorithm (ECDSA)”. It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US. The core signature used in Bitcoin and Ethereum is ECDSA (Elliptic Curve Digital Signature Algorithm), and which uses a random nonce for each signature. The nonce value should never repeat or be revealed. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, an improved proof of work, and smart contracts. Bitcoin is seen as a first-generation blockchain, and Ethereum as a second-generation. These have been followed by third-generation blockchains, such as IOTA, Cardano and Polkadot — and which have improved consensus mechanisms. Bitcoin uses a consensus mechanism which is based on Proof-of-Work, and where miners focus on finding a block hash that has a number of leading “0”s. The difficulty of the mining is defined by the hashing rate. At the current time, this is around 424 million TH/s. There are around 733,000 unique Bitcoin addresses being used. Satoshi defined a reward to miners for finding the required hash. This was initially set at 50 BTC, but was set to half at regular intervals. On 11 January 2021, it dropped from 12.5 BTC to 6.2 BTC. Bitcoin currently consumes around 16.27 GWatts of power each year to produce a consensus — equivalent to the power consumed by a small country. In creating bitcoins, Satoshi created a P2PKH (Pay to Public Key Hash) address. These addresses are used to identify the wallet to be paid and links to the public key of the owner. These addresses start with a ‘1'. In order to support the sending of bitcoins to and from multiple addresses, Bitcoin was upgraded with SegWit (defined in BIP141). The wallet address then integrates the pay-to-witness public key hash (Pay to script hash — P2SH). These addresses start with a ‘3'. Ethereum uses miners to undertake work for changing a state and running a smart contract. They are paid in “gas” or Ether and which relates to the amount of computation conducted. This limits denial of service attacks on the network and focuses developers on creating efficient code. Ethereum supports the creation of cryptocurrency assets with ERC20 tokens — and which are FT (Fungible Tokens). For normal crypto tokens (ERC-20) we use, there is a finite number of these, and each of these is the same. Ethereum creates NFTs (Non-Fungible Tokens) with ERC721 tokens. We mint these each time and each is unique. Solidity is the programming language used in Ethereum, while Hyperledger can use Golang, Node.js and Java. For Ethereum, we compile Solidity code into EVM (Ethereum Virtual Machine) code. This is executed on the blockchain. Blockchain uses the SHA-256 hash for transaction integrity. Ethereum uses the Keccak hash is used to define the integrity of a transaction. This is based on SHA-3, and differs slightly from Keccak. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, and standardized by NIST in August 2015 as SHA-3. The DAO is a decentralized autonomous organization (DAO) for the Ethereum blockchain and was launched in 2016. In 2016, DAO raised $150 million through a token sale but was hacked and funds were stolen. This resulted in a forking of the blockchain: Ethereum and Ethereum Classic. Non-interactive Zero Knowledge Proofs (NI-ZKP) allow an entity to prove that they have knowledge of something — without revealing it. A typical secret is the ownership of a private key. NI-ZKPs involve a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled, “Non-interactive zero-knowledge and its applications”. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge). Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero. In 1992, David Chaum and Torben Pryds Pedersen published “Wallet databases with observers,” and outlined a method of shielding the details of a monetary transaction. In 1992, Adi Shamir (the “S” in RSA) published a paper on “How to share a secret” in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS). In 1991, Torbin P Pedersen published a paper entitled “Non-interactive and information-theoretic secure verifiable secret sharing” — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version, and has better support for signature aggregation. It uses Twisted Edwards Curves. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as, a “Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system”. The patent ran out in 2008. Curve 25519 uses the prime number of ²²⁵⁵-19 and was created by Daniel J. Bernstein. Peter Shor defined that elliptic curve methods can be broken with quantum computers. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name of “bulletproofs” is defined as they are short, like a bullet, and with bulletproof security assumptions. While Bitcoin can take up to 7–10 minutes to mine a new block and create a consensus, newer blockchains, such as IOTA, can give an almost instantaneous consensus. Banks around the world are investigating CBDC (Central Bank Digital Currency) and which is not a cryptocurrency but a way to quickly define a consensus on a transaction. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge. Open Zeppelin is an open-source Solidity library that supports a wide range of functions that integrate into smart contracts in Ethereum. This includes AES encryption, Base64 integration and Elliptic Curve operations. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers. Solidity programs can be compiled with Remix at remix.ethereum.org. The main Ethereum network is Ethereum Mainnet. We can test smart contracts on Ethereum test networks. Current networks include sepolia.etherscan.io and goerli.net. Ether can be mined for test applications from a faucet, such as faucet.metamask.io. This normally requires some proof of work to gain the Ether — in order to protect against a Denial of Service against the Faucet. The private key can be revealed from two ECDSA signatures which use the same random nonce value. Polkadot is a blockchain which allows blockchains to exchange messages and perform transactions. The proof of work method of creating is now not preference because of the energy that it typically uses. Many systems now focus on proof of stack (PoS). A time-lock puzzle/Proof of Work involves performing a computing task which has a given cost and which cannot be cheated again. This typically involves continual hashing or continual squaring. The Chia blockchain network uses both Proof of Space (PoS) and Proof of Time (PoT). The PoS method makes use of the under-allocation of hard-disk space. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wireless and transistors. This can be used to link a device to an NFT. In Blockchain applications, we can use Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) — DLEQ. With this — in discrete logarithms — we have
Related page: https://medium.com/asecuritysite-when-bob-met-alice/clocks-latex-byzantine-generals-and-post-quantum-crypto-meet-the-amazing-leslie-b-lamport-b2ade4b590d7 Demo: https://asecuritysite.com/hashsig/lamport Introduction I write this article in Medium and with its limited text editor, but I really would love to write it in LaTeX. Before the monopoly of Microsoft Word, there were document mark-up systems such as Lotus Manuscript, and where we had a basic editor to produce publishing-ready content. The GUI came along, and all the back-end stuff was pushed away from the user. For many, this is fine, but for those whose output is focused on sharing and dissemination of research, it is often the only way to work. In research, LaTeX is King and is a fully formed method of laying out — and sharing — research outputs. In the past few years, we have published over 100 research papers, and not one of them has been created in Microsoft Word. And for this, I thank Leslie Lamport. In fact, ask our kids about Newton, Faraday or Einstein, and they could probably tell you something about them. But ask them about Whitfield Diffie, Shafi Goldwasser, or Leslie B Lamport, and they would probably look quizzical? Their future world, though, is probably going to be built around some of the amazing minds that built the most amazing structure ever created … The Internet. To Leslie Lamport So, I am so privileged to be an academic researcher. For me, teaching, innovation and research go hand-in-hand, and where the things I research into gives me ideas for innovation, and which I can then integrate these things into my teaching. The continual probing of questions from students also pushes me to think differently about things, and so the cycle goes on. But, we are all just building on the shoulders of true giants, and there are few larger giants than Leslie Lamport — the creator of LaTeX. For me, every time I open up a LaTeX document, I think of the work he did on creating LaTeX, and which makes my research work so much more productive. If I was still stuck with Microsoft Office for research, I would spend half of my time in that horrible equation editor, or in trying to integrate the references into the required format, or in formatting Header 1 and Header 2 to have a six-point spacing underneath. So, for me, the contest between LaTeX and Microsoft Word is a knock-out in the first round. And one of the great things about Leslie is that his work is strongly academic — and which provides foundations for others to build on. For this, he did a great deal on the ordering of task synchronisation, in state theory, cryptography signatures, and fault tolerance. LaTeX I really can say enough about how much LaTeX — created in 1984 — helps my work. I am writing a few books just now, and it allows me to lay out the books in the way that I want to deliver the content. There's no need for a further mark-up, as I work on the output that the reader will see. But the true genius of LaTeX is the way that teams can work on a paper, and where there can be async to GitHub and where version control is then embedded. Overall we use Overleaf, but we're not tie-in to that, and can move to any editor we want. But the process is just so much better than Microsoft Word, especially when creating a thesis. Word is really just the same old package it was in the 1990s, and still hides lots away, and which makes it really difficult to create content which can easily be changed for its layout. With LaTeX, you create the content and can then apply whatever style you want. Clocks Many in the research community think that the quality measure of a paper is the impact factor of the journal that it is submitted to, or in the amount of maths that it contains. But, in the end, it is the impact of the paper, and how it changes thinking. For Leslie, in 1978, his paper on clocks changed our scientific world and is one of the most cited papers in computer science [here]: Byzantine Generals Problem In 1981, Leslie B Lamport defined the Byzantine Generals Problem [here]: And in a research world where you can have 100s of references in a paper, Leslie only used four (and which would probably not be accepted these days for having so few references): Within this paper, the generals of a Byzantine army have to agree to their battle plan, in the face of adversaries passing in order information. In the end, we aim to create a way of passing messages where if at least two out of three of the generals are honest, we will end up with the correct battle plan. So why don't we build computer systems like this, and where we support failures in parts of the system, or where parts of the system may be taken over for malicious purposes? And the answer is … no reason, it just that we are stuck with our 1970s viewpoint of the computing world, and everything works perfectly, and security is someone else's problem to fix. So, we need a system where we create a number of trusted nodes to perform a computation, and then an election process at the end to see if we have a consensus for a result. If we have three generals (Bob, Alice and Eve), we need two of them to be honest, which means we can cope with one of our generals turning bad: In this case, Eve could try and sway Trent by sending the wrong command, but Bob and Alice will build a better consensus, and so Trent will go with them. The work can then be defined as MPC (Multiparty Computation) and where we have multiple nodes getting involved to produce the final result. In many cases, this result could just be as simple as a Yes or No, and as to whether a Bitcoin transaction is real or fake, or whether an IoT device has a certain voltage reading. The Lamport Signature Sometime soon we perhaps need to wean ourselves of our existing public key methods and look to techniques that are more challenging for quantum computers. With the implementation of Shor's algorithm [here] on quantum computers, we will see our RSA and Elliptic Curve methods being replaced by methods which are quantum robust. One method is the Lamport signature method and which was created by Leslie B. Lamport in 1979 [here]: At the current time, it is thought to be a quantum robust technique for signing messages. When we sign a message we take its hash and then encrypt it with our private key. The public key is then used to prove it and will prove that we signed it with our private key. The Lamport signature uses 512 random hashes for the private key, and which are split into Set A and Set B. The public key is the hash of each of these values. The size of the private key is 16KB (2×256×256 bits) and the public key size is also 16 KB (512 hashes with each of 256 bits). The basic method of creating a Lamport hash signature is: We create two data sets with 256 random 256-bit numbers (Set A and Set B). These are the private key (512 values). Next, we take the hash of each of the random numbers. This will give 512 hashes and will be the public key. We then hash the message using SHA-256, and then test each bit of the hash (0 … 255). If it is a 0, we use the ith number in Set A, else we use the ith number from Set B. The signature is then 256 random numbers (taken from either Set A or Set B) and the public key is the 512 hashes (of Set A and Set B). This process is illustrated below: We can use the Lamport method for one-time signing, but, in its core format, we would need a new public key for each signing. The major problem with Lamport is thus that we can only sign once with each public key. We can overcome this, though, by creating a hash tree which is a merger of many public keys into a single root. A sample run which just shows the first few private keys and the first public keys: ==== Private key (keep secret) =====Priv[0][0] (SetA): 6f74f11f20953dc91af94e15b7df9ae00ef0ab55eb08900db03ebdf06d59556cPriv[0][1] (SetB): 4b1012fc5669b45672e4ab4b659a6202dd56646371a258429ccc91cdbcf09619Priv[1][0] (SetA): 19f0f71e913ca999a23e152edfe2ca3a94f9869ba973651a4b2cea3915e36721Priv[1][1] (SetB): 04b05e62cc5201cafc2db9577570bf7d28c77e923610ad74a1377d64a993097ePriv[2][0] (SetA): 15ef65eda3ee872f56c150a5eeecff8abd0457408357f2126d5d97b58fc3f24ePriv[2][1] (SetB): 8b5e7513075ce3fbea71fbec9b7a1d43d049af613aa79c6f89c7671ab8921073Priv[3][0] (SetA): 1c408e62f4c44d73a2fff722e6d6115bc614439fff02e410b127c8beeaa94346Priv[3][1] (SetB): e9dcbdd63d53a1cfc4c23ccd55ce008d5a71e31803ed05e78b174a0cbaf43887==== Public key (show everyone)=====Pub[0][0]: 7f2c9414db83444c586c83ceb29333c550bedfd760a4c9a22549d9b4f03e9ba9Pub[0][1]: 4bc371f8b242fa479a20f5b6b15d36c2f07f7379f788ea36111ebfaa331190a3Pub[1][0]: 663cda4de0bf16a4650d651fc9cb7680039838d0ccb59c4300411db06d2e4c20Pub[1][1]: 1a853fde7387761b4ea22fed06fd5a1446c45b4be9a9d14f26e33d845dd9005f==== Message to sign ===============Message: The quick brown fox jumps over the lazy dogSHA-256: d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592==== Signature =====================Sign[0]: 4b1012fc5669b45672e4ab4b659a6202dd56646371a258429ccc91cdbcf09619Sign[1]: 04b05e62cc5201cafc2db9577570bf7d28c77e923610ad74a1377d64a993097eSign[2]: 8b5e7513075ce3fbea71fbec9b7a1d43d049af613aa79c6f89c7671ab8921073Sign[3]: 1c408e62f4c44d73a2fff722e6d6115bc614439fff02e410b127c8beeaa94346The signature test is True In this case, we take the random number and then convert it to a string. So the SHA-256 signature of “6f74f11f20953dc91af94e15…0db03ebdf06d59556c” is 7f2c9414db83444c586c…49d9b4f03e9ba9. If can be seen that the hash of the message (“The quick brown fox jumps over the lazy dog”) has a hex D value at the start, which is 1101 in binary, and we see we take from SetB [0], SetB [1], SetA [2] and SetB [3]. A demonstration is given here. Conclusions The Internet we have now built on the foundations that Leslie applied. On 18 March 2013, he received the AM Turing Award (which is like a Nobel Prize in Computer Science). At the time, Bill Gates said: Leslie has done great things not just for the field of computer science, but also in helping make the world a safer place. Countless people around the world benefit from his work without ever hearing his name. … Leslie is a fantastic example of what can happen when the world's brightest minds are encouraged to push the boundaries of what's possible. Basically, much of our computing world is still using the amazing foundation that was created in the 1970s and 1980s. We tip our hats to Diffie Hellman, Shafi Goldwasser, Ralph Merkle, Ron Rivest, Adi Shamir, and, of course, Leslie B Lamport. As a note, that while Leslie's paper on Clocks is cited over 12,000 times, the Diffie Hellman paper is cited over 19,300 times: We really should be integrating computer science into our school curriculum, and show that it has equal standing to physics, biology and chemistry, and it will shape our future world as much as the others. Why not teach kids about public-key cryptography in the same way that we talk about Newton?
Related material Main page: https://billatnapier.medium.com/cryptography-fundamentals-8-rsa-rivest-shamir-and-adleman-445b91932bd0 RSA: https://asecuritysite.com/rsa Introduction In August 1977, The Stranglers were in the music charts with “Something Better Change” and something really was changing, and it was something that would change the world forever. This was the month that Martin Gardner in his Scientific American column, posted a challenge of a method that has stood the test of time: RSA. It related to the work of R(ivest), A(dleman) and S(hamir) and was a puzzle on their discovery of a method which allowed two keys to be created, where one could encrypt and the other to decrypt. Their work had been based on a proposal from Whitfield Diffie and Martin Hellman on trapdoor functions that could be used to create the key pair. Mathematical Puzzles introducing RSA In order to explain the RSA concept, Martin's provided a background the Diffie-Hellman method for which he outlined: Then in 1975 a new kind of cipher was proposed that radically altered the situation by supplying a new definition of "unbreakable." a definition that comes from the branch of computer science known as complexity theory. These new ciphers are not absolutely unbreakable in the sense of the one-time pad. but in practice they are unbreakable in a much stronger sense than any cipher previously designed for widespread use. In principle these new ciphers can be broken. but only by computer programs that run for millions of years! Overall the Diffie-Hellman method has had a good run, but it has struggled in recent years to keep up with the processing power for computers, and the millions of years of running is not quite the case in the modern area, and where the original ciphers could now easily be broken with the simplest of computers within minutes. With the RSA method, Martin Gardner outlined: Their work supported by grants from the NSF and the Office of Naval Research. appears in On Digital Signatures and Public-Key Cryptosystems (Technical Memo 82. April. 1977) issued by the Laboratory for Computer Science Massachusetts Institute of Technology 545 Technology Square. Cambridge Mass. 02139.The memorandum is free to anyone who writes Rivest at the above address enclosing a self-addressed. 9-by-12-inch clasp. On receipt the requesters eventually (it took over four months in many cases) received a precious piece of history (Figure ref{fig03}). RSA research paper It seems unbelievable these days, but the original methods were based on two 63-digit prime numbers that would be multiplied to create a 126-digit value: Contrast this with the difficulty of finding the two prime factors of a 125- or 126-digit number obtained by multiplying two 63-digit primes. If the best algorithm known and the fastest of today's computers were used, Rivest estimates that the running time required would be about 40 quadrillion years' A 256-bit number, at its maximum, generates 78-digits: 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665, 640,564,039,457,584,007,913,129,639,936 Web: https://asecuritysite.com/encryption/keys3 The 40 quadrillion years has not quite happened, and where 512-bit keys are easily broken in Cloud. If you are interested, here is a 512-bit integer value and which has 148 digits, such as: 13,407,807,929,942,597,099,574,024,998,205,846,127,479,365,820,592,393,377,723,561,443,721,764,030,073,546,976,801,874,298,166,903,427,690,031,858,186,486,050,853,753,882,811,946,569,946,433,6 49,006,084,096 web: http://asecuritysite.com/encryption/random2 The search for prime numbers, too, has been progressive since 1977, and by 2014, the world discovered a 17,425,170-digit prime number. The finding of prime numbers make the finding of them in the RSA method must easier. So the RSA method has been under attack for years, from both discovering prime numbers and also in factorizing. Along with this computing power has increased massively. If think that 40 years that have passed, and take a quick assumption that computing power doubles every year then we get: 1977 4 Quadrillion Years (4,000,000,000,000,000)1978 2 Quadrillion Year1979 1 Quadrillion Year…2020 227 years2021 113 years2022 57 years2023 28 years and if we get a GPU card with 4,000 processors, we take it to less than a year, and we get of few of them today into a cluster, and we crack it within one day! The FREAK vulnerability was actually caused by the limiting of RSA keys, due to US Export controls, to 512-bits. The factorising of prime numbers too has generated methods which can quickly find the prime number factors The Tension of Crypto and Academic Freedom Once Martin had published the article, the requests for the article came rushing in, especially as the paper had not yet appeared in the Communication of the ACM. Initially there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. Why did it take so long to get the paper published and also to send them out? Well the RSA method caused significant problems within the US defence agencies. This was highlighted in a letter sent from J.A.Meyer to the IEEE Information Theory Group on a viewpoint that cryptography could be violating the 1954 Munitions Control Act, the Arms Export Control Act, and the International Traffic in Arms Regulations (ITAR), and could thus be viewed equivalent to nuclear weapons. In even went on to say that: Atomic weapons and cryptography are also covered by special secrecy laws The main focus of the letter was that any work related to cryptography would have to be cleared by the NSA before publication. In fact, the letter itself had been written by Joseph A Meyer, an employee of the NSA. Joseph had already been embroiled in controversy with a proposal to fit a tracking device to the 20 million US citizens who had been associated with crime. The tag would then be used to monitor the location of the “subscriber”, and to detect when they broke a curfew or committed a crime. In this modern era of GPS tracking of everyone's phones, Joseph's dream has actually become a reality, but now everyone is monitored. The RSA team thus had a major dilemma, as many of the requests for the paper come from outside the US. Martin Hellman, who was a co-author of the Diffie-Hellman method, had already had problems with ITAR, and even decided to present thep aper himself in 1977 at Cornell University rather than the practice of letting his PhD students present the work. His thinking was that the court case would be lengthy, and that it would damage his PhD student's studies (Ralph Merkle and Steve Pohlig), and so he stood up for academic freedoms. Initially the students wanted to present their work, but their families did not think it a good idea. Eventually though, Ralph and Steve stood beside Hellman on the stage to present the paper, but did not utter a word. With this stance the cryptographers held ground, and hoped that a stated exemption on published work within ITAR would see them through. The worry, though, did delay the paper being published, and for the posting of the article. In reply to Meyer's letter, the IEEE stood its ground on their publications being free of export licence controls, with the burden of permissions placed on the authors: RSA research paper and then additional response from the IEEE saying they put in place safeguards for the publishing of material. The scope of the impact of RSA was perhaps not quite known at the time with Len Adleman stating: I thought this would be the least important paper my name would ever appear on In fact, Adleman has said that he did not want his name on the paper, as he had done little work on it, but he did insist that his name went last. Often papers, too, have an alphabet order, and if so the method could have been known as the ARS method … not the kind of thing that you would want to say to audiences on a regular basis. RSA Within cryptography we typically use non-negative integer values, and perform integer operations. The challenge in public key encryption is to find a method which is computationally difficult for a computer to solve, if it does not know a given secret (normally the private key). One such problem is the difficulty in factorizing a value made up of the multiplication of two large prime numbers. In RSA, we take two large prime numbers — typically at least 512 bits long — and then multiply these together to create a modulus value, (N) (often at least 1,024 bits long). From this, we then derive a public exponent (e) and a modulus. The modulus N is thus determine by multiplying the two prime numbers (p and q): N = p x q The core challenge here is that it should be extremely difficult (and costly) to determine the two prime numbers which make up N. Next we select the value of our encryption key value for the public key (e). This is selected so that N and e do not share any factors: gcd(e,PHI)=1, and where PHI = (p-1)(q-1) This is known as Euler's totient function. The most typical value we use for e is 65,537 (0x10001). To produce a cipher (C), we convert our message into the form of an integer (M) and then use e and N to give: C = M^e mod N To decrypt this, we take the cipher (C), and recover the message value using the decryption exponent (d) and the modulus (N): M = C^d mod N To make RSA work, we then need to calculate the private exponent (d) to obey: (d x e) mod{PHI} = 1 and where phi is: PHI = (p-1)(q-1) We determine d by determining the inverse of e modulus phi: d = e^{-1} pmod {phi} So let's take p=11 and q=7, and pick e of 3. N will be: N=p.q = 77 PHI is 6x10=60 We can't pick e of 3 or 5, so we will pick e=7. Now we compute the decryption exponent of d = e^{-1} mod (PHI) >>> pow(7,-1,60) 43 If we select a message of 19, we get a cipher of: C=19⁷ (mod 77) = 68 Now to decrypt: M= 68⁴³ (mod 77) = 19 Our public key is then (e,N) and the private key is (d,N). The usage of the (mod N) operation is the magic that makes this work. Unfortunately, the RSA method has suffered from performance issues as we have increased the size of the prime numbers used. Thus, if researchers can crack a modulus of 1,024 bits, they will factorize the two 512-bit prime numbers used. At the current time, a public modulus of 2,048 bits is recommended. So while a modulus of this size is acceptable within a powerful computer, devices which have limited CPU resources often struggle in creating the keys, and in the encryption and decryption process. RSA Signatures With the mathematical operations involved, RSA is hardly ever used for core encryption, as symmetric key methods are much more efficient in their implementation. But it is fairly efficient when dealing with relatively small data sizes, such as for a symmetric key (typically only 128 bits or 256 bits long). For this, Alice might protect a symmetric key with her public key, and whenever she needs to use it, she will decrypt it with her private key. Another area where we use RSA is to take a hash of a message, and then encrypt this with the private key. As the hash is relatively small (such as 128 bits, 160 bits or 256-bits), it is relatively efficient on the use of the computing resources. Where public key encryption methods come in most use is within creating digital signatures, and where Bob can take a hash of a message, and then encrypt this hash with his private key. Alice can then also take a hash of the received message, and decrypt Bob's encrypted hash with his public key, and compare the values produced. If they match, she determines that it was Bob who sent the message and that it has not been changed by anyone. In Figure ref{fig_trust03} we see that Bob has a key pair (a public key and a private key). He takes a hash of the message and encrypts with his private key, and then appends this to the message. This and then message will be encrypted by the symmetric key that Bob and Alice share (typically this is either a long-term shared key, or has just been negotiated through a hand-shake). When she receives the ciphered message, she decrypts it with the shared symmetric key, and then takes her own hash of the message. She also decrypts the encrypted hash using Bob's public key, and then compares the hashes. As the public key and the private key work together, only the signing by Bob's private key will reveal the hash with his public key. Alice can then tell that the message has not been changed — as the hash would change if Eve has modified it — and that it was produced by Bob (and not by Eve pretending to be Bob). Obviously, we now have a problem in how we get Bob's public key. An important element here, is that they have to find a way for Bob to send Alice her public key in a trusted way, so that Eve cannot intercept it, and change the keys. For this, we introduce Trent, and who is trusted by Bob and Alice to prove their keys. For this Trent signs the public key of Bob with his private key, and then Alice uses Trent's public key to prove Bob's public key. For a few decades, RSA has been the main method in supporting public key encryption. We often use it when we connect to a secure Web site, and where the RSA method is used to prove the identity of the Web site. In this case the RSA public key of the site is presented to the user in the form of a digital certificate — and which is signed by a trusted source. The Web site can then prove its identity by signing a hash of the data with its private key, and the client can check this. A typical size of the public modulus is now 2,048 bits (created by two 1,024 bit prime numbers), and with some sites supporting 4,096 bits. So while desktop computers have the processing power to cope with these large numbers, less able devices (such as for low processing powered IoT — Internet of Things — devices) will often struggle to perform the necessary calculations. Simple example So let's take a simple implementation of RSA key generation, encryption and decryption. In this case the code is: Web: https://asecuritysite.com/encryption/rsa12 In this case, we generate two random prime numbers ($p$ and $q$) for a given number of bits. The more bits we use, the more secure the method is likely to be, as an increase in the number of bits increases the number of prime numbers that can be searched for. Once we have these, we then determine the public modulus ($N$) by multiplying the prime numbers together. The difficulty of the problem is then factorizing this modulus back into the prime numbers. If we have the public modulus, it is fairly simple to then find the decryption exponent value. In most modern examples of RSA, we select a public exponent value ($e$) of 65,537, and so our encryption key becomes $(65,537,N)$. The decryption exponent ($d$) is then the inverse of $e pmod {phi}$ (and where $phi=(p-1)(q-1)$). from Crypto.Util.number import *from Crypto import Randomimport Cryptoimport libnumimport sysbits=60msg="Hello"p = Crypto.Util.number.getPrime(bits, randfunc=Crypto.Random.get_random_bytes)q = Crypto.Util.number.getPrime(bits, randfunc=Crypto.Random.get_random_bytes)n = p*qPHI=(p-1)*(q-1)e=65537d=libnum.invmod(e,PHI)## d=(gmpy2.invert(e, PHI))m= bytes_to_long(msg.encode('utf-8'))c=pow(m,e, n)res=pow(c,d ,n)print ("Message=%snp=%snq=%snnd=%dne=%dnN=%snnPrivate key (d,n)nPublic key (e,n)nncipher=%sndecipher=%s" % (msg,p,q,d,e,n,c,(long_to_bytes(res))))end{lstlisting} A test run using 60-bit prime numbers is: Message=hellop=242648958288128614541925147518101769011q=299356840913214192252590475232148200447N=72638625604016464006874651287120524699932001616388639276131104258310920947917cipher=5847803746095553957863305890801268831081138920772806292673259864173015661385decipher=hello Conclusions RSA has been around for over 46 years, and is still going strong. It can encrypt and it can sign. While the prime numbers involved has got larger, and it needs to have padding applied, it is still one of the best public key methods around, and well used on the Web.
Cryptography Fundamentals 5: GCD, Extended GCD and Group Generators This podcast will outline a few building blocks of cryptography: GCD (Greatest common divisor), extended GCD and group generators. These you will find in many related cryptography papers, and any weaknesses in these can cause significant problems to the overall security of a method. Greatest common divisor— GCD A fairly simple concept that is used within public key encryption is the greatest common divisor (GCD). With this, we take two integer values and determine the largest factor that they are. Overall, every non-prime number is made up of the multiplication of prime numbers. For example: 32,128 = 2 x 2 x 2 x 2 x 2 x 2 x 2 x 251 36,281 = 7 x 71 x 73 So, the GCD of 56 and 42 is 14, as both of the values can be factorized into 4 x 14 and 3x14, respectively. https://asecuritysite.com/principles_pub/gcd Normally we use this function to find values which do not share a factor, as we will see when selecting the public exponent (e) in the RSA method. The method to determine the GCD is fairly simple, and where we take two values (a and b) and use the modulus operation to find the GCD: def gcd(a, b): while( b != 0 ): Remainder = a % b; a = b; b = Remainder; return a;g = gcd(679,99)print g A sample run shows that 679 and 99 do not share any factors: a:679, b:99, Remainder:85a:99, b:85, Remainder:14a:85, b:14, Remainder:1a:14, b:1, Remainder:0Return value:1 Web: https://asecuritysite.com/encryption/gcd Extended GCD GCD is the greatest common divisor. For two integers (x and y), the extended GCD method solves ax+by=v for a and b, and where v=gcd(x,y). One example of using the Extended GCD method is to determine the modulo inverse of a value (the inverse value of n (mod p) so that: n⋅n^{−1}=1 (mod p) ). 30a+20b=gcd(30,20). Soln: a=1, b=−1. Try! 35a+15b=gcd(35,15) . Soln: a=1, b=−2. Try! Group generator In reading about cryptography, have you ever come across the term of a cyclic group G of order p and with a generator g? With a discrete log mapping, we map x to Y with Y=g^x (mod p) where we have a generator value (g) and a prime number p. The challenge is that even though we know Y, g and p, it is extremely difficult to determine the x value if we use a large prime number. But can we use any value of g, and should it be as large as possible? The answer to both of these questions is no. If we select a prime number of 11, and then select g values of 2, 3, 4 …10, and then calculate the results we get [spreadsheet]: Now look at g=2 and p=11, for 2¹ (mod 11) we get 2, 2² (mod 11) we get 4, 2³ (mod 11) we get 8, and so on. As we see {1,2,3,4,5,6,7,8,9,10} gives {2,4,8,5,10,9,7,3,6,1}, and where all the input values give a 1-to-1 mapping to another value in the group. But if we try g=3 and p=11, we get x=1 gives 3, and for x=6 also gives 3. The mapping is now {1,2,3,4,5,6,7,8,9,10} to {3,9,5,4,1,3,9,5,4,1}, and so we are not using the full range, and where there would be a confusing for mapping back to our original value. But, in order to demonstrate the principle, I have done this in a long-handed way, so how do I find out all the possible values of G for a given prime number (p)? Well, here's a nice simple method in Python that I created to test up to p): import sysdef issafe(g,p): exp=1 rand=g next = rand % p while (next != 1 ): next = (next*rand) % p exp = exp+1 if (exp==p-1): return True else: return Falsep=11g=4if (len(sys.argv)>1): p=int(sys.argv[1])if (len(sys.argv)>2): g=int(sys.argv[2])print ("Is g={0} safe for p={1}? {2}".format(g,p,issafe(g,p)))print ("xtg^xtg^x (mod p)")for x in range(0,10): print ("{0}t{1}t{2}".format(x,pow(g,x),pow(g,x,p))) A sample run with an unsafe value is: Is g=3 safe for p=13? Falsex g^x g^x (mod p)0 1 11 3 32 9 93 27 14 81 35 243 96 729 17 2187 38 6561 99 19683 1 and where the only output value is 1, 3 and 9. For a safe value, we get: Is g=3 safe for p=17? Truex g^x g^x (mod p)0 1 11 3 32 9 93 27 104 81 135 243 56 729 157 2187 118 6561 169 19683 14 So, how does this work in practice? Well, rather than picking the prime number and then finding a g value which will work, we typically pick the g value we want, such as for g=2, g=3 or g=5, and then find a prime number of a given size to work with that value. This will slow down the process, as we might have to pick a few prime numbers before we find one that will work. An example command in OpenSSL to generate the Diffie-Hellman parameters for g=3 and a 512-bit prime number is: openssl dhparam -text -3 512DH Parameters: (512 bit) P: 00:ff:1a:a6:fd:94:1b:55:8c:03:e0:ba:91:d5:e3: 23:40:6a:8e:49:a1:d4:d9:dd:68:3f:10:3d:ff:a7: a6:8e:2f:9f:f9:3f:4d:dc:3d:54:71:e0:aa:65:dc: 24:03:42:73:39:db:d6:02:a6:dc:bd:ac:49:12:a8: dc:d0:57:d9:bf G: 3 (0x3) https://asecuritysite.com/openssl/dh
Preface We should all have a magic switch that pushes aside our worries and replaces them with something that takes our woes away. So, when I've had a long and tiring day, and there are things buzzing in my head — I don't count sheep, I ponder the wonder of discrete logarithms, and in the magical ways they have solved our many online security. It relaxes me and pushes out all of those academic stresses. This academic year, we were so lucky to speak to some of the people who properly built the foundations of our online security. This included Marty Hellman (co-inventor of the Diffie-Hellman method), Tahir ElGamal (inventor of the ElGamal encryption method), and Neal Koblitz (co-inventor of Elliptic Curve Cryptography — ECC). In this article, I will trace the roots of this security, and outline how discrete logs paved the way for the rise of ECC. So, if we go back to school, you will remember that: g^x . g^y is equal to: g^{x+y} and that: {g^x}^y is: g^{x.y} That's the beauty of logarithms. Introduction Our online world is secured with discrete logs. While we have moved away from discrete logs for key exchange (Diffie-Hellman), encryption (ElGamal) and digital signatures (DSA), at the core of the security of elliptic curves is the Elliptic Curve Discrete Logarithm Problem (ECDLP): Can we find n such that Q = nP? and where P and Q are points on an elliptic curve, and where we have a finite field defined by a prime number. The curve itself can be the form of: y²=x³+ax+b (mod p) The (mod p) part defines a finite field, and which basically constrains the values of x and y to between 0 and p-1. But, I'd like to look back at a time before elliptic curves and see where we started with this: the discrete log. Basically, discrete logs built the security of the Internet, and without them, we would have struggled to advance from a digital world that used physical cables and padlocks to secure itself.
In this episode of ACM ByteCast, Rashmi Mohan hosts 2015 ACM A.M. Turing Award laureates Whitfield Diffie and Martin Hellman. As joint creators of the Diffie-Hellman key exchange, they introduced the world to the transformative idea of public key cryptography, the underpinning of every secure transaction on the internet today. Whitfield has spent a large portion of his career as a security practitioner, including roles at Northern Telecom and Sun Microsystems. He is an elected Foreign Member of the Royal Society and a recipient of numerous other awards and accolades in computing. He's currently a consulting scholar at the Center for International Security and Cooperation at Stanford University. Martin is a Professor Emeritus of Electrical Engineering at Stanford University. He's also a recipient of the RSA Lifetime Achievement Award, among many other recognitions. Both have received the Marconi Prize and have been inducted into the National Cybersecurity Hall of Fame and the National Inventors Hall of Fame. Whitfield and Martin share their individual journeys to computer science and cryptography, which were shaped both by personal interests and the geopolitical realities of the time. They also describe how they met and developed a rapport with each other as researchers. They share their “aha moment” in public key cryptography and how the internet catapulted commercial cryptography in the 1990s. They also share their thoughts on computing privacy, national security, and quantum computing and its implications for both Diffie-Hellman and RSA (Rivest-Shamir-Adleman) cryptosystems. They touch on end-to-end encryption and the field of technology in the next five years. Along the way, they share colorful details from their early years and share advice for young people aspiring to get into computing
Could you explain Apache Kafka® in ways that a small child could understand? When Mitch Seymour, author of Mastering Kafka Streams and ksqlDB, wanted a way to communicate the basics of Kafka and event-based stream processing, he decided to author a children's book on the subject, but it turned into something with a far broader appeal.Mitch conceived the idea while writing a traditional manuscript for engineers and technicians interested in building stream processing applications. He wished he could explain what he was writing about to his 2-year-old daughter, and contemplated the best way to introduce the concepts in a way anyone could grasp.Four months later, he had completed the illustration book: Gently Down the Stream: A Gentle Introduction to Apache Kafka. It tells the story of a family of forest-dwelling Otters, who discover that they can use a giant river to communicate with each other. When more Otter families move into the forest, they must learn to adapt their system to handle the increase in activity.This accessible metaphor for how streaming applications work is accompanied by Mitch's warm, painterly illustrations.For his second book, Seymour collaborated with the researcher and software developer Martin Kleppmann, author of Designing Data-Intensive Applications. Kleppmann admired the illustration book and proposed that the next book tackle a gentle introduction to cryptography. Specifically, it would introduce the concepts behind symmetric-key encryption, key exchange protocols, and the Diffie-Hellman algorithm, a method for exchanging secret information over a public channel.Secret Colors tells the story of a pair of Bunnies preparing to attend a school dance, who eagerly exchange notes on potential dates. They realize they need a way of keeping their messages secret, so they develop a technique that allows them to communicate without any chance of other Bunnies intercepting their messages.Mitch's latest illustration book is—A Walk to the Cloud: A Gentle Introduction to Fully Managed Environments. In the episode, Seymour discusses his process of creating the books from concept to completion, the decision to create his own publishing company to distribute these books, and whether a fourth book is on the way. He also discusses the experience of illustrating the books side by side with his wife, shares his insights on how editing is similar to coding, and explains why a concise set of commands is equally desirable in SQL queries and children's literature.EPISODE LINKSMinimizing Software Speciation with ksqlDB and Kafka StreamsGently Down the Stream: A Gentle Introduction to Apache KafkaSecret ColorsA Walk to the Cloud: A Gentle Introduction to Fully Managed EnvironmentsApache Kafka On the Go: Kafka Concepts for BeginnersApache Kafka 101 courseWatch the videoJoin the Confluent CommunityLearn more with Kafka tutorials, resources, and guides at Confluent DeveloperUse PODCAST100 to get an additional $100 of free Confluent Cloud usage (details)
Bu hafta Kerem Kocaer ve Murat Lostar, kuantum bilgisayarlar için geliştirilen şifreleme algoritmasının kırılmasını ve Cisco'nun hack'lenmesini ele alıyor. NIST tarafından 2016 yılında kuantum bilgisayarlara dayanıklı algoritmalar geliştirilmesi amacıyla bir yarışma başlatıldı. Geçtiğimiz ay ise ABD Ticaret Bakanlığı'nın Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) RSA, Diffie-Hellman gibi algoritmaların yerini alacak dört kuantum sonrası şifreleme algoritması seçti. Son 4'e kalan algoritmalardan biri olan SIKE (Supersingular Isogeny Key Encapsulation) KU Leuven araştırmacıları tarafından 1 saat içinde kırıldı. Yanluowang isimli fidye yazılımı grubu Cisco'nun sistemlerine sızarak 2.8 GB'lık veriyi ele geçirdi. Mayıs ayında yaşanan bu olay, geçtiğimiz hafta hacker'ların Cisco'dan ele geçirdikleri verilerin ekran görüntülerini yayımlamasının ardından ortaya çıktı. Cisco ise olayla ilgili açıklamayı ise bu hafta yaptı. Keyifli dinlemeler.
Episode 012 | May 30, 2022Neeraj Kayal: It's just a matter of time before we figure out how computers can themselves learn like humans do. Just human babies, they have an amazing ability to learn by observing things around them. And currently, despite all the progress, computers don't have that much ability. But I just think it's a matter of time before we figure that out, some sort of general artificial intelligence.Sridhar Vedantham: Welcome to the MSR India podcast. In this podcast, Ravishankar Krishnaswamy, a researcher at the MSR India lab, speaks to Neeraj Kayal. Neeraj is also a researcher at MSR India and works on problems related to or at the intersection of Computational Complexity and Algebra, Number Theory and Geometry. He has received multiple recognitions through his career, including the Distinguished Alumnus award from IIT Kanpur, the Gödel prize and the Fulkerson Prize. Neeraj received the Young Scientist Award from the Indian National Science Academy (INSA) in 2012 and the Infosys Prize in Mathematical Sciences in 2021. Ravi talks to Neeraj about how he became interested in this area of computer science and his journey till now.For more information about the Microsoft Research India click here.RelatedMicrosoft Research India Podcast: More podcasts from MSR IndiaiTunes: Subscribe and listen to new podcasts on iTunesAndroidRSS FeedSpotifyGoogle PodcastsEmailTranscriptRavi Krishnaswamy: Hi Neeraj, how are you doing? It's great to see you after two years of working from home.Neeraj Kayal: Hi Ravi, yeah thank you.Thank you for having me here and it's great to be back with all the colleagues in office.Ravi Krishnaswamy: First of all, congratulations on the Infosys prize and it's an amazing achievement.And it's a great privilege for all of us to have you as a colleague here.So, congratulations on that.Neeraj Kayal: Thank you.Ravi Krishnaswamy: Yeah, so maybe we can get started on the podcast. So, you work in complexity theory, which is I guess one extreme of, I mean, it's very theoretical end of the spectrum in computer science almost bordering mathematics. So hopefully by the end of this podcast we can, uh, I mean, convince the audience that there's more to it than intellectual curiosity. Before that right, let me ask you about how you got into theoretical computer science and the kind of problems that you work on. So, could you maybe tell us a bit about your background and how you got interested into this subject?Neeraj Kayal: Yeah, so in high school I was doing well in maths in general and I also wrote some computer programs to play some board games, like a generalized version of Tic Tac Toe where you have a bigger board, say 20 by 20, and you try to place five things in the row, column, or diagonal continuously and then I started thinking about how could a computer learn to play or improve itself in such a game? So, I tried some things and didn't get very far with that, but at that time I was pretty convinced that one day computers will be able to really learn like humans do. I didn't see how that will happen, but I was sure of it and I just wanted to be in computer science to eventually work on such things. But in college in the second year of my undergrad, I enrolled for a course in cryptography taught by Manindra Agrawal at IIT Kanpur and then the course started off with some initial things which are like fairly predictable that something called symmetric key cryptosystems where, essentially it says that let's say we two want to have a private conversation, but anyone else can listen to us. So how do we have a private conversation? Well, if we knew a language, a secret language which no one else did, then we could easily just converse in that language, and no one will understand this. And so, this is made a little more formal in this symmetric key cryptosystem. And then, one day, Manindra ended one of the lectures with the following problem: but now suppose we did not know a secret language. Then we just know English, and everyone knows English and then how do we talk privately when everyone can hear us? I thought about it for a few days. It seemed completely impossible. And then Manindra told us about these wonderful cryptosystems, called the Diffie Hellman cryptosystem and the RSA cryptosystem where they achieved this and it was very surprising. And the key thing that these cryptosystems use is something that lies at the heart of computer science, a big mystery still even to this day at the heart of computer science. There are these problems which we believe are hard for computers to solve in the following sense, that even if a computer takes a very long amount of time, if we give it a fairly long amount of time, a reasonable amount of time it cannot solve it. But if we give it time like till the end of the universe, it can in principle solve such problems. So that got me interested into which problems are hard and can we prove they are actually hard or not? And to this day, we don't know that.Ravi Krishnaswamy: So, I'm guessing that you're talking about the factoring problem, right?Neeraj Kayal: Yes, factoring is one of the big ones here. And the RSA cryptosystem uses factoring.Ravi Krishnaswamy: So, it's actually very interesting, right? You started out by trying to show that some of these problems are very, very hard, but I think, looking back, your first research paper, which happens to be a breakthrough work in itself, is in showing that a certain problem is actually easier to solve. Then we had originally thought right so, it is this seminal work on showing that primality testing can be solved in deterministic polynomial time. I mean, that's an amazing feat and you had worked on this paper with your collaborators as an undergrad, right?Neeraj Kayal: Yes.Ravi Krishnaswamy: Yeah, that's an incredible achievement. So maybe to motivate others who are in undergrad and who have an interest and inclination in such topics, could you maybe share us some story on how you got working in that problem and what sort of led you to this spark that eventually got you to this breakthrough result?Neeraj Kayal: So, my advisor Manindra, who also was the professor who taught us cryptography - he had been working on this problem for a long time and there were already algorithms that existed which are very good in practice- very very fast in practice, but they had this small chance that they might give the wrong answer. The chance was so small that practically it did not matter, but still as a mathematical challenge, it remained whether we could remove that small chance of error, and that's what the problem was about. So, Manindra had this approach and he had worked with other students also- some of our seniors- on it, and in that course, he came up with a conjecture. And then when we joined, me and my colleague Nitin, we joined this project , we came across this conjecture and my first reaction was that the conjecture is false. So, I tried to write a program which would find a counterexample and I thought we would be done in a few days-Just find that counterexample and the project would be over. So, I wrote a program- it will train for some time, didn't find a counterexample, so I decided to parallelize it. A huge number of machines in the computer center in IIT Kanpur started looking for that counterexample. And then to my surprise, we still couldn't find the counterexample. So there seemed to be something to it. Something seemed to be happening there which we didn't understand, and in trying to sort of prove that conjecture, we managed to prove some sort of weaker statement which sufficed for obtaining the polynomial time algorithm to test if a number is prime or not. But it was not the original conjecture itself. Many days after this result came out, we met a mathematician called Hendrik Lenstra who had worked on primality testing, and we told him about this conjecture. And after a few days he got back to us and it showed that if you assume some number theoretic conjecture is true, which we really really believe, it's true.Ravi Krishnaswamy: Ok, I see. So, the original conjecture, which you hoped to prove true is false, but the weaker conjecture was actually true, you proved it to be true, and that was enough for your eventual application.Neeraj Kayal: Yes, so in some sense we are very lucky that in trying to prove something false we managed to prove something useful.Ravi Krishnaswamy: Yeah, I mean it's a fascinating story, right? All the experiments that you ran pointed you towards proving it, and then you actually went and proved it. If you had found, I imagine what would have happened if you found a counterexample at that time, right?Neeraj Kayal: So yeah, Hendrix proof was very interesting. He showed that modulo this number theory conjecture a counterexample existed. But it would have to be very, very large and that's why you couldn't find it. So, he explained it beautifully.Ravi Krishnaswamy: Yeah, thanks for that story Neeraj. So. I guess from then on you've been working in complexity theory, right?Neeraj Kayal: That's right, yeah.Ravi Krishnaswamy: So, for me at least, the Holy Grail in complexity theory that I've often encountered or seen is the P versus NP problem, which many of us might know. But you've been working on a very equally important, but a very close cousin of the problem, which is called the VP versus VNP problem, right? So, I'm going to take a stab at explaining what I understand of the problem. So, correct me whenever I'm wrong. So, you are interested in trying to understand the complexity of expressing polynomials using small circuits. So, for example, if you have a polynomial of the form X ^2 + Y ^2 + 2 XY, you could represent it as a small circuit which has a few addition operations and a few multiplication operations like you could express it as X ^2 + Y ^2 + 2 XY itself. Or you could express it as (X + Y)^2. Which may have a smaller representation in terms of a circuit. So, you have been working on trying to identify which polynomials have small representations and which polynomials are natural but still don't have small representations.Neeraj Kayal: That's right.Ravi Krishnaswamy: Is that a reasonable approximation of the problem you're thinking about?Neeraj Kayal: Yes, that's right. So, another way to put the same thing is what is the power of computation when you do additions, multiplications, subtractions, all these arithmetic operations. You could include division, square roots also.Ravi Krishnaswamy: So, I have seen this VP class and it makes a lot of sense to me. It's the set of all the polynomials that can be captured by small sized circuits with the plus I mean addition and multiplication gates. I've also seen the VNP class, which seems to me at least to be a bit mysterious, right? So, these are all the polynomials whose coefficients of the individual monomials can be computed efficiently. Is that a reasonable definition, at least? Is my understanding correct?Neeraj Kayal: Yeah, that's the technical definition of this class, but there's another natural sort of intuition why we want to look at it, and the intuition is that it relates to counting the number of solutions to a problem, and also therefore to computing probabilities of various things happening.Ravi Krishnaswamy: I see. Ok, so that gives me a lot more understanding. I guess when you're able to estimate probabilities, you could also do sampling over those objects.Neeraj Kayal: Yes exactly.Ravi Krishnaswamy: Yeah, that's a very nice connection. I did not know about this. Thanks for that. So, you have been working, you have an agenda on trying to show some sort of a separation between the two classes, right, VP and VNP, by constructing these low depth circuits. So, you're able to show that all polynomials in VP have admit the low depth representation and your hope in this agenda is to find one polynomial in VNP which does not have a low depth representation, right?Neeraj Kayal: That's right.Ravi Krishnaswamy: So, how far are you in this agenda and do you think we have all the tools needed to actually achieve success through this sort of a method?Neeraj Kayal: Yeah, so just historically for converting a circuit or a program into a low depth program, this was done earlier. Most of this work was done by other people. So, we haven't contributed much in that direction. We have been trying to prove certain polynomials don't have small depth and small sized arithmetic circuits. So, it's not clear to us whether the existing techniques are good enough to prove this or not. And like on Mondays, Wednesdays, and Fridays, I think they are capable maybe, and on the other days I think maybe not. And this is what researchers generally deal with. Especially in these areas where you don't know whether your tools are good enough or not. And very recently, just last year, there was a big breakthrough by trio of complexity theorists who showed somewhat good lower bounds for all constant depth arithmetic formulas or circuits. And what was surprising also about this result is that, they use in a very clever way, techniques that were already known.Ravi Krishnaswamy: So, they would have probably shown it on a Monday or Wednesday or Friday.Neeraj Kayal: Yes, yes. [Laughs]Ravi Krishnaswamy: OK, that's very interesting. So, you still don't know whether this will lead to success or not through this route.Neeraj Kayal: Yes, yeah, we still don't know that.Ravi Krishnaswamy: Are there other people approaching this problem through other techniques?Neeraj Kayal: So, there's a program called the Geometric Complexity Theory program initiated independently by other people who basically try to understand symmetries. Because implicit in this question is a whole bunch of symmetry, then they try to exploit that. And there's a field of mathematics called group theory and representation theory, which is all about understanding symmetries of objects. That area is beautiful, really beautiful, and a lot of advancement has been made there. So, people have been trying to also attack this problem through using those tools.Ravi Krishnaswamy: Yeah, that's very nice, I think. So basically, you're saying a lot of like diverse techniques from math and computer science are at play here and trying to help you on your progress.Neeraj Kayal: That's right.Ravi Krishnaswamy: I see. I mean, it's very beautiful. I find it fascinating and beautiful that a lot of these different diverse techniques from mathematics and computer science come into play into establishing these lower bounds. And what's more fascinating to me is that they are all not just from an intellectual curiosity standpoint. They seem to be powering a lot of things that we take for granted, right, right from, like, as you said, messaging each other through social networks or whatever it is. They seem to be like at the foundation- the inherent hardness of certain problems seem to be at the foundation of a lot of things that we take for granted.Neeraj Kayal: Yeah, that's right, Ravi. So, for example, I do transactions using my mobile phone and anyone who is within a reasonable distance of my mobile phone can read all the signals that my phone is sending. So, they can see all the communication that I'm having with the bank. And the fact that despite that they are not able to infer my banking passwords relies on the fact that certain problems are very inherently hard to solve and that's what we are trying to prove.Ravi Krishnaswamy: OK, so that's very interesting Neeraj. And in the last part of this podcast, I want to flip the topic around a little bit. So, you've been working a lot on showing lower bounds, and in lower bounds in arithmetic complexity. But lately in the last couple of years you have also been using those insights into showing some very nice algorithms for some learning problems. I find that also very cool, so maybe you can talk a little bit about that.Neeraj Kayal: Yeah, so the algorithms that we are trying to devise are trying to solve the following problem. More general version of it is the following. Given a function or a polynomial, what's the smallest number of operations that you need to do to be able to compute that function or polynomial? So, for Boolean functions this has a very long history. That essentially is like designing chips, and you can imagine it was naturally very useful to think about. But more recently, it turns out a lot of works have found another very surprising connection because of which this problem specifically for polynomials has also become very interesting. And the connection is this. Suppose you have some very big data set. For now, think of this data set as consisting of a bunch of points in high dimensional space. For example, you can think of images as a point, every image as a point in the high dimensional space. Now it turns out that you can take statistics of this data. So, for example, you can take what's the average value of the first coordinate, what's the average value of the second coordinate? Or what's the average value of the product of the first two coordinates in this data set and so on. So, you can take some of these statistics, encode them as the coefficients of a polynomial. And here's the interesting part. When the data has some very nice structure, then this polynomial tends to have a small circuit.Ravi Krishnaswamy: I see.Neeraj Kayal: And so, when you want to understand the structure of data, so this general area is called unsupervised learning. Turns out that it's useful to find small circuits for polynomials. So, this is the computational problem that we are looking at: given a polynomial, what's the smallest number of operations, or what's the smallest circuit representing this polynomial.Ravi Krishnaswamy: So, if you're able to find the smallest circuit representing this, then from that you will be able to infer the underlying distribution or the structure of the underlying data.Neeraj Kayal: Yes, yes, that's right. So, this is one connection, and it also turns out that the lower bounds that we are proving, showing that certain things are very hard to compute are also useful for now devising algorithms to find the circuits of polynomials which do have small circuits and maybe let me give you some very rough sense of how that comes about, and I find this a bit fascinating. Here's how the lower bounds proofs work. So, underlying all those lower bounds for the various subclasses of circuits that we do have is a collection of linear maps and now it turns out that when you are given a polynomial which has a small circuit, using this polynomial and the collection of linear maps, which go into the lower bound proof you can form another big linear map, such that, very roughly, the eigen spaces of this new linear map correspond to the smallest circuit for F.Ravi Krishnaswamy: I see.Neeraj Kayal: And this was the connection that we discovered some time ago, which helped us find small circuits.Ravi Krishnaswamy: So, you find small circuits by computing the eigen space of the of the map.Neeraj Kayal: Yes, of this other linear map. That's right Ravi.Ravi Krishnaswamy: I see that's very nice. Ok, so I think we covered a lot of the topics that I wanted to cover, so maybe I'll end with two philosophical questions. So, one is you began the podcast by talking about how as a kid, you thought computers or machines could be able to do everything that human intelligence can do. So, I think it's a vague question, but what's your take on that now? And two is what advice would you give for budding theoreticians, whether they're in school or college or grad school? What sort of advice would you give them?Neeraj Kayal: So, for the first question, Ravi, I know a lot of other people also share this feeling, that it's just a matter of time before we figure out how computers can themselves learn like humans do. Just human babies, they have an amazing ability to learn by observing things around them. And currently, despite all the progress, computers don't have that much ability. But I just think it's a matter of time before we figure that out, some sort of general artificial intelligence. To your second question, Ravi, I don't have much to offer other than perhaps a banal comment that anyone looking to work in this area should really enjoy thinking about these kinds of problems. They tend to be rather abstract, sometimes the applications are not always apparent, but if you enjoy thinking about them, I'm sure you'll do well.Ravi Krishnaswamy: That's great, Neeraj. It's been a pleasure chatting with you. Thanks a lot for your time and hope you had fun.Neeraj Kayal: Yeah, thanks Ravi. Thanks a lot for having me.
Network Security with KevTechify on the Cisco Certified Network Associate (CCNA)
In this episode we are going to look at IPsec Overview.We will be discussing IPsec Concepts, IPsec Technologies, IPsec Protocol Encapsulation, Confidentiality, Integrity, Authentication, Secure Key Exchange with Diffie-Hellman, and finally IPsec Transport and Tunnel Modes.Thank you so much for listening to this episode of my series on Network Security for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Network Security v1 (NetSec)Episode 18 - VPNsPart C - IPsec OverviewPodcast Number: 73-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment
Network Security with KevTechify on the Cisco Certified Network Associate (CCNA)
In this episode we are going to look at Confidentiality.We will be discussing Data Confidentiality, Symmetric Encryption, Asymmetric Encryption, Confidentiality, Authentication, Integrity, Diffie-Hellman, Cryptography, Classify the Encryption Algorithms, and finally Encrypting and Decrypting Data Using OpenSSL.Thank you so much for listening to this episode of my series on Network Security for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Network Security v1 (NetSec)Episode 16 - Basic Integrity and AuthenticityPart C - ConfidentialityPodcast Number: 67-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment
In this episode we are going to look at IPsec.We will be discussing IPsec Technologies, IPsec Protocol Encapsulation, Confidentiality, Integrity, Authentication, and finally Secure Key Exchange with Diffie-Hellman.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3 (ENSA)Episode 8 - VPN and IPsec ConceptsPart C - IPsecPodcast Number: 42-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment
In this episode we are going to look at Cryptography.We will be discussing Data Integrity, Hash Functions, Origin Authentication, Data Confidentiality, Symmetric Encryption, Asymmetric Encryption, and Diffie-Hellman.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 3 - Network Security ConceptsPart J - CryptographyPodcast Number: 19-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment
See their public Notion doc which got me very interested: https://www.notion.so/Comm-4ec7bbc1398442ce9add1d7953a6c584They are hiring: https://www.notion.so/commapp/We-re-hiring-b0a4cef3f8b34b8c91e3236c98aabcb3Watch the video version if you prefer that (there is some screensharing at the end): https://youtu.be/lWCOruAWpW4---Transcriptswyx: [00:00:00] Some of you might know that I do some angel investing on the side and I keep a cold email address open for that purpose. So a few weeks ago I was called emailed from someone trying to raise money for an end to end encryption startup. And that's something that I don't normally play in because they don't know anything about encryption.So I almost turned this down except I click through and read their notion doc. And it's the most comprehensive and concise pitch I've ever received through a cold email. So I took the meeting and this conversation with Ashoat is what happened. He's building Comm, which is an end to end encryption startup, but his go to market is an alternative end to end self hosted version of discord, focused on privacy.Of course. The long term vision is that it could replace Dropbox, Gmail, Facebook, Mint, 1Password, and so on. If he gets this key server protocol right, and successful, he gets some kind of market adoption. So that's a very big if, but the upside is also huge. And whenever you encounter one of these things, that becomes a very interesting angel investment because you'll probably lose your money, but if it succeeds, it succeeds very big.He's looking to hire senior engineers and a product and a design lead. So stick towards the end for those hiring and collaboration details. If you are interested, all right. Enjoy. Yeah, good to meet you too, man. It was very impressive. Your notion doc. Ashoat Tevosyan: [00:01:26] Thanks. I'm glad you read it. A lot of folks kind of skim through so it's great to see that you want in detail.Wait, so, so you wanted to record this right? Was that swyx: [00:01:35] yeah. Literally it's just like adjusting. I think it would be interesting to either share if you want to, if you. Don't mind sharing. We can always cut stuff out if you're not comfortable with it or you can just keep it to yourself and then look back in four years or something and think about how things have changed.It's always nice to request stuff. Ashoat Tevosyan: [00:01:54] Yeah. Yeah. I'm when you say shared, do you have like a social media thing that you want to share? Yeah, I have, swyx: [00:01:59] I have a YouTube or an F a personal podcast where I recorded conversations that are interesting with people. Ashoat Tevosyan: [00:02:05] Yeah. I'm honestly, I'm down. I'll tell you, I've done.I've done this pitch like a hundred times now, so I'm pretty good at it. So I'm pretty comfortable being recorded. Let me ask this, what's your setup? I sometimes record meetings. I use green, but I think that's more for I don't know getting transcripts to share with the team and stuff like that.I don't know. What do you usually use? swyx: [00:02:23] For recording. Yeah. I mean, I've, because zoom is going to kick out two audio sources. Then I might edit in audacity for echo or like noise or whatever. And then the scripts for cutting out ums and AHS and word gaps and stuff like that.Sometimes if a conversation needs a lot of VR rearranging, I might have to like, so I did this one episode where. There was the two guys talking about a concept, tofu, MOFU, and BOFU, top of funnel, middle funnel, and bottom of funnel. And they'd collected to define it until the end of the episode.He spent the entire epistle talking about it and I had to go cut the thing and then put it on top and then, Ashoat Tevosyan: [00:03:03] yeah. Okay. Okay. I got it. I got it. It sounds like you have a more, much more professional setup than I do. So, I mean, whatever works for you, swyx: [00:03:10] it's immature. Put with a little effort put in. I think people can get along way towards instead of just dumping raw audio, which most people seem to do.Ashoat Tevosyan: [00:03:19] Cool. swyx: [00:03:20] Yeah. Cool. So I read through it, I read through your thing, which is why, I, it seems like you've practiced this for a bit. You have a really interesting background. I've always wanted to visit as a Biogen. Like when I saw backhoe, I was like, wow. I recognize that for me, I was memorizing it Ashoat Tevosyan: [00:03:33] just some background.I think we Armenian and there is huge ethnic tension between Armenia is or vagina. You can. Think of my family more as refugees. Yeah. Were like Armenian refugees from Azerbaijan. We actually can't visit us every Shawn. If an Armenian person with an Armenian name tries to visit as her vagina, they won't let you in, my parents have not been able to visit their home since they were kicked out.So yeah. It's a weird background, but yeah. Just that swyx: [00:03:58] I'd share that. Yeah. Cool. That's cool. Lots of history. The, obviously the most famous Armenian I know is a Sonoma session on the Conan show. Who is that? I Ashoat Tevosyan: [00:04:08] don't know who that is. swyx: [00:04:10] Yeah. She's Ashoat Tevosyan: [00:04:12] yeah. Okay. She's like his production assistant or something.swyx: [00:04:15] Just straight up assistant. Yeah. But I think now she's a little bit more into it since then. She's he turns his staff into celebrities. Ashoat Tevosyan: [00:04:22] Oh, that's cool. That's cool. I only seen some secondhand Conan material floating around. I don't want it. swyx: [00:04:27] Well, they visited Armenia and they learned a bit about the history and the genocide there and all that.So, It's heavy stuff. I didn't obviously pay super close attention to the police history, but I know that there's a, there's some heavy stuff going on. Okay. And then you joined Facebook super the it's just like a really inspiring story, man. And that's pretty cool.I'm unclear on, you said you worked on comms for four years. I'm unclear on like when that transition happens, why it happens? Because it takes a certain. Awakening to quit Fang and start work on something. So fringe, I think it's been, Ashoat Tevosyan: [00:04:59] I don't know. I don't know. Pretty fruit and share.Yeah. Yeah. So, so a couple of things, first, when I say I've been working on calm for four years, I actually only got the idea for this like whole antenna Christian platform. About a year ago. So when I say been working on it for four years, I mean, as well, the code base I'm working with has been around for four years and I've been pretty actively working on it.But before it was common, something called squad cat, which is basically this app I built for my friend group, it's like a slacker friend group with an integrated calendar. And specifically the star was my burning man camp were like 200 people and we have this problem. We've tried like Slack, we've tried discord.You have this problem where we were simultaneously very scammy. We like shoot the shit, have fun, But we also have all these deadlines and all this project collaboration that needs to happen. And on these platforms it's often very difficult to separate signal from noise.It feels like they're built to be, just span out everything. You're thinking. And there aren't a lot of tools there to say, I want to follow this. Or I want to make sure, I get updates here, but maybe I'll only check this channel when I'm on the toilet or something, and they're getting better.They're rolling off features, but I still feel like it's like a second kind of priority. It's not something that's really at the forefront. So that's a large part of why I built squad cab. The other kind of side of it is I use different my own friend group here in New York. And yeah, I've been working on it for a while, but off and on, honestly.And only about a year ago, And I, when I started working on the antenna encryption layer, which I always wanted to do, it's something that kind of the, the pandemic happened that was stuck at home. I was like, what am I going to do? And I decided to work on that antenna encryption layer only then when I really got the idea for comm.And since then also we were really pivoting a lot of the apps. So there's been a calendaring focus and now it's being put to the side and being framed as the first app. And there's actually meant to be like, any number of apps that you can install to your community.You had this, the other question you can ask, like what, what made me leave Facebook? So, I guess, I guess it's probably best to start with the story of how I joined Facebook. So. I guess I was like a wide-eyed college student. Background is I actually, I've always been, I love kind of social.And my programming, has always kinda been from that angle. My whole family is actually programmers like my mom and my dad, my uncle and my cousin and my sister, everyone. It's kinda crazy. And I learned how to program pretty young, but I found most of it boring. Like my P my parents gave me Kane R when I was 12.And it's read through it, read some, a calculator, command, prompt apps. And I was like, this is not fun. And honestly, I really only got into it when I discovered PHP and forms. That's what really got me excited. And this is like circle like 2000, 3004. And all my early programming was like modding forms.So I had this From where I had all my friends on come online, we like hung out there. I like skinned it and then started adding these like different mods. I actually, at the time, there's this model of posting for hosting which, you probably don't remember unless you were spending all the time back then, but basically the idea is you go on a forum, you post a bunch, they'll give you free hosting for your own website.Right. And so we started doing that and we offered like a lot of features and got pretty popular pretty quickly. For a while we were, if you Googled free hosting, the first site was his directory and we were listed this number one on that directory. So we were like the largest free host for a long time.This is a lot of my kind of college years, actually more high school. And then early college was like also building on automating that, that kind of hosting service. And we actually we scaled it to intense amount. Like we scaled to the point where, so we use this control panel C panel. There were. We had more accounts on our server than they did when they did the load testing.Like they had like internal load testing. They did, we had all this like customization we did to make that happen. So anyways, long story short, I was really into social, always having into social and Facebook came out for high schoolers, got really into it. I started posting everything on Facebook and which is, I guess, common back then.And I wrote several browser extensions for Facebook and one of them added a search box to your profile. And that one got pretty popular. Right. And I personally used it because I. Facebook. And I always wanted to like, have a conversation with somebody like, wait, like I want to share this article with you.And I would forget who wrote it or what, where it was from. And so I would want to search my own profile and I used to just click see more posts manually until I found it. So that's what my browser extension did. I wrote in like a weekend. And it would just click see more posts for you, whatever.So anyways, that guy got me noticed by Facebook and noticed I like applied through like the college program. And then the recruiter I'd mentioned this, the recruiter, and she said it was cool anyways. So I got an internship there, his sophomore year. This is 2011. So give you some background.Facebook at the time was like one, two story building. There was technically two buildings, but like most of engineering was in product and design was in this one building. Right. And it was just, it was, it felt crazy. Like it felt I mean, Facebook was already huge at the time. Right. And it felt every, and there's no politics.Everyone was like working together. Everyone knew each other. It was. Felt like a pretty magical place. And on my second day there was a hackathon and some this hackathon I'm like, okay, I'm going to do, I'm going to take the search thing that I built and I'm gonna make it happen for real.So I got a little team together. We got nowhere on that first day. Like it turns out it's way harder to build a search index. Than it is to click this, let me make this look, browser extension that click see more posts, but I kept on working on it every day. Like after, after work, I worked on it a bit more and made a little bit more progress.And probably what made me fall in love with the company was halfway through my internship. My managers told me to forget about my assigned intern project. Then I could just work on my hackathon thing. So yeah, it was like a kid. I was like, that was so amazing. Right. So I didn't ever left Facebook. I like kept working there.I worked on the project alone for a year, so I was so on this project building the surgeon X for a year. And after a while actually became a major strategic priority for the company. There was a goal to create like a whole like search and expert posts. And it was amazing. We built at the time, the largest index in the world, but that's on authority of the Google engineers we poached.So it was like the entire search team was working on this. I was a very small part, there's each like genius C plus plus people like my mentor, read the entire sequence plus 11 spec to give you an idea. A single replica of our index is 25 racks in a data center. And each of them was outfitted with these like fusion IO cards.Which were at the time, like the thing there was some sort of in between Ram and hard drive or it's like a, yeah, it was like a precursor to flash drives, I guess it was a kind of flash drive, but we bought out all of the flashcards. There were some Taiwanese company we bought all of them.It was so expensive anyways. So this is a background after that I worked at kept working on Facebook. I wanted to try something new. So we, I moved to New York. Started a new team called public conversations at the time, every time Mark posted on Facebook, he just got standing comments. So you wanted to make this better.And I always had this passion for discourse. So I wanted to improve the quality of discourse on Facebook. So I was our, that was our team motto. We were improving the quality of discourse on Facebook initially from the common ranking stack, which we built out initially was just like ripped off from Reddit.We built out all of this like natural language processing, deep learning stuff that I honestly don't have. Full understanding of but that team was amazing. It was great to, I was engineering manager also vaguely the PM cause we never managed to staff with him. But so what made me leave Facebook?I'll tell you is It was a confluence of things and it, at the time, like it was a very difficult decision, but it also felt like a very clear decision. And what I mean by that is basically with all we had this team going public conversations seem that I loved. And after several reorgs, we were in an org called media.And Mark got really excited about live video in 2016. And so he did this company-wide lockdown and then he rotated our entire org to work on live video. So my perspective, I, I'm no issues with live video. Like I'm, it's sure. It makes sense as a company priority, but it's not my passion, so there was that there was also, this happened at the same time as my four year vest. Right. And so all these factors pointing to like this is probably the time to leave. Yeah. Let's see. Yeah. I had a pretty I, my final meeting with my director, I was like tearing up and stuff.It was pretty intense in retrospect, probably more intense than it needed to be. But this is a business decision. swyx: [00:12:19] Yeah, that's fine. Yeah. Yeah. Yeah. But they like, th they were a big part of your growth, right? From college. Like you, you didn't have to finish college too.And then you worked at one of the fastest green companies on earth. Like it's a big part of your identity that you're leaving behind. Ashoat Tevosyan: [00:12:32] Absolutely. I felt, yeah, like it's hard to overstate, like Facebook, to me, wasn't really a company. It was like the only company I've ever worked at. It was like, to some extent, like it's exaggerating, but there was an aspect of being like a, like a family in the sense that like I had done this internship with all these interns in 2011 and we all felt pretty connected and we'd saved the company and it like, yeah, I dunno.I don't think it was good that it felt this way to me, but that's how it felt. Let's put it that way. I just, swyx: [00:12:57] I, I love a little, a few of the tippets here. First of all, working on the thing that you think should exist and then eventually the company comes around and recognizes it that I think that's a very common thing I see in smart people that like, you should just ignore what people will tell you is the priority and think for yourself.And obviously you should do your job, but then also you have to have some leadership there and then people will eventually recognize it. And then the second thing is the way the market tends to lock down the company at critical stages. I'm sure you were there for the mobile pivot as well.Ashoat Tevosyan: [00:13:25] yeah. That was huge people. People forget it now, but there was a time when Facebook wasn't. Yeah, there was a time when Facebook wasn't guaranteed. There's a time when, after Facebook IPO, the stock went down, like everyone was saying, Facebook's not going to make it. Which in retrospect, like nobody, nobody could see that being a concern now, but yeah.swyx: [00:13:45] Yeah. Well then yeah. Anyway it's pretty cool. And yeah it's cool to hear another story about that. But okay. Let's bring it a little bit closer to time. So then you left did you have a clear idea of what you were going to do? Ashoat Tevosyan: [00:13:54] No. Well, so, background about me is that I'd held a job since I was 14.So I had have like multiple jobs, like grocery store bagger, like a teaching assistant at Kumon, like all this, like PR like internships and so I just been working forever. So I wanted to basically try, spend some time not working. So I, and I did post Facebook, did he have some traveling, did some like other cool projects.I worked on this really cool actually burning man project where we built this like 16 foot tall dome that had 7,500 LEDs that animated with the music. So that was a really cool problem. Just like between the processing audio and the like led stuff. It was really fun. I worked with a close friend of mine who was like a hardware expert, so he was able to build all the hardware and I was able to do all like the software.No was like a multi-year project. But yeah also working on squad cow that app I talked about and yeah, just a lot of source stuff. swyx: [00:14:42] And then I guess, so you're pivoting constantly. You got you started with more like a collaboration thing, then it was more of a calendar thing.And now it's more focused on chat. What is it based on, what is this like a product instinct that you're having, or is there a community that you're closely connected to? That's giving you all this feedback? Is it just friends. Yeah. Ashoat Tevosyan: [00:15:01] Well, so, so I wouldn't say I'm pivoting constantly. I mean, honestly, the app was a passion project and wasn't really like a startup where was with a startup, you're like, you're trying to find something to hit send.You're trying to like pivot until you find it. I started this thing with this kind of focus on calendaring and focus on collaboration. Just things that we needed as a camp. And in terms of the pivot to calm that all happened a year ago. So that all happened with a year ago.I start working and I think cryption. I realized I can't build the antenna encryption layer. It literally was impossible. I would have to roll back a bunch of my features. And then I start thinking and realize, okay, actually it's impossible to build most apps with antenna encryption. You can only build these like simple chat apps, which is great.And I'm a huge fan of signal, but that's all we can do today. Right. And so from there, I realized, okay, you know what, in the future, the only way we're going to get to privacy by default, the only way we're going to get to antenna, encryption, being something that scales is that people have their own servers.Right. And so once I had that realization, I worked backwards of okay what's the most likely thing that's going to hit. That's going to get an install base of key servers going, because I think whoever builds this first installed base of key servers is going to be really well positioned to capture this market.And that's what led me to pivoting the app. swyx: [00:16:10] Can I I need to, because I don't think I understand this very well. So you can do it entering a question for Chad. I don't understand what that the material difference is between chat and every other type of app, because it's just the transport layer.LikeAshoat Tevosyan: [00:16:23] Yeah, that's exactly right. It's just a transport layer and that's limitation. Right? So the average app you see out there, it looks, let's take Slack. As an example, Slack is built with it's a client server model, right. And this is how apps have been built since the Dawn of time. Since back in 2004, when I was writing PHP apps, actually it was mostly server back then, but there's always been a server layer.Right. And what does the server layer do? Right. Well, classic stuff includes like executing search query is like ranking, right? Does a lot of stuff. Right. Fundamentally, usually with a client server model, you have a thin client. The kind of client that, when it starts up connects to the server and asks the server, what do I need to display?The server tells it everything. And the client just like only keeps around what it needs in the cash. The next time it connects, it gets to that same background and end to an encrypted chat app is nothing like this. Right? An antenna encrypted chat app takes all that server stuff. Puts it onto the client.And then the server is just a message broker. And all the server does is, you say, I want to send a message to user X. It receives that message, queues it up. And then when user XX connects it, flushes that queue, that's all that's going on. Right. And the reason for that fundamentally is because antenna encryption is about being able to guarantee to the user.That the app developer doesn't have access to their data and not just the app developer, also governments also service providers, but really it's about the app developer. Right. And with a server layer like Slack has Facebook has like Dropbox has obviously the app developer has access to your data.Right. And you, the only thing you can really do with that encryption is you can put cipher text up there, but all the typical stuff that a server needs to do with the exception of maybe backup, most of it requires actually having access to that plain text. And that's why apps like signal apps, like WhatsApp.Have basically no server layer. Right. swyx: [00:18:01] Okay. So, does that also mean that, I mean, let's say there's an existing history, your database of documents and stuff. Like when I first connected, I have to download the full thing. Is Ashoat Tevosyan: [00:18:10] this what do you mean? Sorry, is this for an app? swyx: [00:18:13] No Maybe an athletic signal, but I'm just talking generic.Like how do you deal with data? Right. Cause you're just saying like just the queue now. Meaning that you know what? I don't know how to to me, this is obvious, like in the client server model, the server keeps all the state. Right. So now when a state, when a service, just to just the queue, there's no state on the server, essentially.There's a little bit of state with tracking hoots who sings, what? But that big if I were to build notion yeah. Encrypted, where does the database go? Ashoat Tevosyan: [00:18:41] Great question. Yeah. Yeah. Okay. So, so there's a, there's several kinds of points to talk about here. So with something like signal or WhatsApp that uses the double ratchet protocol, which is the protocol that signal introduced that preserves a principle called forward secrecy.There, it gets much more difficult to back up encrypted data. Now I'll go into that in a second, but as a default, if you build something like for instance, Keybase take, took this approach of giving up on forward secrecy and using a single symmetric key. For an entire chat room. If you take that approach, you actually can back up data.You can backup cipher text, right? Because signal and WhatsApp don't take that approach. Their server has no backup and that's crucial to understand if you've ever tried backing up your WhatsApp data, the way it works is you go through a menu tree and then you pick iCloud or depending on if you're iOS or Android, iCloud or Google drive, it keeps you have to keep the app open while it like.Serializes encrypts everything. Actually, it doesn't, it's plain text, so there's no encryption, but it takes it and then uploads it and you keep the app open while that's happening. And now you've backed up your data as of that day. If you have some more messages the next day, and then you lose your phone, those messages are gone.If you don't want to spend all this time with the app, open, waiting for it to upload, then there's no backup. I don't know. I don't have the numbers. My guess is most users do not back up their WhatsApp as for signal, no backup. That's just not how they do it. So you've probably had this experience.I don't know if you've ever gotten a new phone and you see your signal chats are missing. Oh, yeah, I have. swyx: [00:20:09] So I have two phones and when I switch SIM cards, just for international travel and stuff like that I can see that the WhatsApp doesn't transfer over. So yeah, that, that makes a lot more sense.Now. I never really questioned why I thought it was just a poor UX decision, but now it's in my spicy it's with a necessary part of the intended question. So is this a fundamental thing? Is that, is this something you're trying to solve where you're just saying this is. Ashoat Tevosyan: [00:20:28] So the backup thing isn't like super fundamental, so, okay.So it might be worth talking about some alternative approaches, right? So, so the two of them might be worth talking about our matrix. Are you familiar with matrix? swyx: [00:20:39] Not really, I was going to ask about it because it's the other big end-to-end chat thing. Yeah, Ashoat Tevosyan: [00:20:44] yeah. Matrix is super cool. They have in a lot of ways, similar model to what we're doing.They have this idea of you have a home server and that your home server tracks your data. And they're a little bit more focused on kind of interoperability and allowing different any different client that you want to use can use the same kind of matrix protocol. But crucially there, the big difference is, for antenna encryption on the matrix platform.It's still client-based right. So your home server doesn't have access to your plain text. That makes sense, because the way they set up home servers, you find a home server provider on the internet somewhere. It's like some service provider, right? So you don't want to just give access to your data to that provider.Right. But matrix has a protocol, an antenna encryption protocol that actually is pretty similar to double ratchet for licensing reasons because they didn't want to use the, a, the BS, sorry, the the GPL license. They built their own and then BSD licensed it. They it's called Megal, but it's pretty much ripped off from from double ratchet.So very similar with forward secrecy. So the way forward secrecy works and the way double ratchet works is every single message that you send has a different encryption key. And that's important to understand, right? So you might think you have just like one encryption key if you and I are having a chat, right.We're just encrypting each message with that same key. Or maybe we each have our own, we encrypt it with that key. That's not what's going on. Actually, each message has its own key. And the ratchet part of double ratchet is every time you send a message, that key gets ratcheted and a new key is created.Right. And why it's called double ratchet is because every time, so let's say I send you four messages, then you send a re a message back. There's a new Diffie-Hellman that occurs. Are you familiar with Diffie-Hellman? Okay. Okay. Backtrack a little bit. So did the Holman is a definitive cryptographic protocol.It was pioneered and then maybe the seventies or eighties, and basically what it does, is it you can imagine two people in a crowded, like a bizarre, let's say you're, somewhere in, in I dunno, Istanbul. And there's a thousand people around you can yell at each other.Like what person a is a secret in the air person. It's not a secret, just like some something, they all, something personally VL something in the air. And from that point on these two individuals can communicate in public encrypted, completely secret in a way that no one else can understand what they're talking about.And they went into this without any prior secrets either. So they met in this spot, they yelled these things out and now they have a secret way of communicating. So if you home is how like TLS works. Like when we go to HTTPS websites, like it's a backbone of everything, right?So when you have anti-corruption defeat divvy home, and it allows you to random individuals to be able to create this like encrypted channel with each other. So with double ratchet and new defi home and occurs every single time, Some like the conversation is switched. Like every time I start talking a new Diffie-Hellman occurs and every time you start talking a new Diffie-Hellman occurs, that's the first ratchet.The second ratchet is every time you send a message, there's a deterministic ratchet. One that both sides can like predict, like to say, okay, this message now gets ratcheted into this key into the scheme to the key. Okay. So all this background is to point out that in order to be able. So, so the default way you would imagine a backup would occur and the default way a backup occurs for an app like messenger is I send you a message before, before Facebook messenger even sends it to you.It backs it up, right? It takes that message and it stores in its database, right? It's a really easy, transparent, automatically backing up. You don't have to manually back anything up. You don't lose your data since the last backup. It's great. Right? The issue is because every single one of these messages has a different key.And because obviously those keys aren't being exposed to that server. Now the server can back up the cipher text, but that cipher text is useless without the keys. And so to really back everything up, you need the clients now to take this giant bundle of keys that they've created to encrypt all of that and to back it up.And that's what matrix does. And matrix has this. You can go on there, GitHub, there's an issue there, and this is a longstanding issue, right? If you log into a web browser for the first time, it freezes the web browser for 10 minutes, because what's happening is it's downloading all of these keys onto your client so that now you can actually get the backup and actually scroll up in your chat history.Right. So that's one approach and it has its limitations. The another approach is will Keybase does, Keybase also tries to solve a, a similar problem with like large chats and they basically gave up on, on Ford secrecy. So their approach is are every chat has a single symmetric key.Right. If you get added to that chat, you get handed that same symmetric key. There's a thousand people. They all have the same symmetric key. It changes. There is some stuff where if someone leaves they need to change the key, there are ways to rotate the keys, but basically ultimately the point of the system is such that, you can join a chat, you can scroll up, see all the history without having to download all these, secondary keys.Their approach is very controversial. In terms of the, like the cryptographic kind of constraints that they're giving up on. It's hard to argue that their form of antenna Christian is as secure as everyone. Else's, they're pretty much the only platform that gave up on Ford secrecy.Everyone else uses double ratchet. It's the standard. So. I usually don't get that deep into this stuff, but yeah it, to really deeply understand why it is, why backup is as broken as it is for antenna encryption today, you really have to understand it from all these angles and then pointing the dimension beyond this as backup is the easy part.So I talked about like search, I talked about ranking backup is by far the easiest problem to solve, right. Trying to build like some homomorphic encryption way for a ranker to be able to see cipher texts and then to still extract interesting features from that cipher text that it can rank.It's like an unsolved problem. I don't imagine it will be solved anytime in the next 20 years, fundamentally to do server stuff, you usually need access to plain text data, and that's the crossroads we're at until we solve that problem. It's, we're going to have simple chat apps on antenna, encryption, and nothing else.Okay. swyx: [00:26:29] But you're trying to go beyond that with the kinds of key server. So, so to be clear, neither matrix, I keep it Keybase do the local key server thing, whatever that is. And I still, I still don't know what it is. And I also wanted to know if there's any desktop equivalent. Cause it seems this is a mobile focused solution. So I was wondering if there's a desktop analogy that we can look at is currently functioning. Ashoat Tevosyan: [00:26:51] So I wouldn't say it's a mobile focused solution, so, okay. So what's a key server. A key server is your own personal data operating system, your own personal kind of like private data cloud today.The world we live in. You have a bunch of accounts. Do you have an account with Facebook? You have an account with Slack, you have account with Google, they all maintain these walled gardens, where your data is stored, right. And they have control of your data. Maybe they'll say you have some control, whatever.Ultimately like you defer to them to manage your digital life. The queue server flips that around. And the key server model, your data is on your device. It's controlled by you and you authorize Facebook, Google, et cetera, to use your key server. And to, either store some data on there or, to enable you to communicate with maybe it's a social app.So you can like chat with your friends, but all of that stuff you allow them to to do that. And crucially the key server controls where that code runs. Right. So you can't, as an app developer, you can't actually have a standalone app, an iOS app with a setup as it is, because that would mean that you could take that data and exfiltrate it, send it to some logging service and analytics service.So it's basically this whole like closed platform that controls. Your data and how it works. And the goal is ultimately to take the cloud and actually to replace it with a federated network of key servers, right. These key servers talk to each other. So a couple of crucial things to understand about a key server.First of all, what, it's not a database and this is important to understand. So a lot of people assume, okay, so this thing has all of your data, right? It actually, it doesn't need to, it can just have your keys. The important thing is right. That it has your keys. Because you can take whatever data you want and you can encrypt that data with their keys and put it out somewhere else in the cloud, you can store it in some IPFS or whatever distributed.It doesn't happen. You don't have to be distributed. Right. The important thing is that this is just a cash, basically. Like you ask it to do operations for you. It pulls down the information it needs and does that stuff and sends the response back. Right? So we're trying to replace not the database layer, but we're trying to replace the cloud code, which is, I guess, these parts terminology, if you remember parse, but like this idea of code that runs in the cloud server layer code, that's what we're ultimately trying to replace.And we're trying to take that and move it to. In an environment that is controlled by the user. So another thing that, can be confusing as like, where does this thing run? Right? So another thing it's that this is not a key server is not a encryption as a service. And what I mean by that is, w we are not offering you, we're not offering a service to run this key server for you.We can't do that because crucially the key server needs access to airplane, text data. So if we're running your key server for you. We have your plain text data, right? So we don't do that. And it's actually, it's up to the user to figure out where they want to run their key server as a default.We offer initially when we launched, we're going to have two ways to do that way. Number one is to take a spare laptop, some laptop that you're not using to plug it into a wall socket, keep it on 24 seven. And that becomes your key server. Right? Option number two is to deploy something to the cloud.And this is we're borrowing Google outline, VPNs approach, where. They basically Google out on weekend, lets you download this like manager thing to your laptop and then it walks you through the process of deploying a VPN to the cloud and you can deploy it to AWS, to Google cloud and even to digital ocean.So our we'll have a similar model where you can deploy to whatever account you want. Obviously, Amazon will have access to your data. Whether that matters to you, I think is depends on the person. I'll say this, like it's not Amazon or Google's business model to be reading your data.I'm pretty sure that they tell you that they don't read your data. And I think only in the case of a government order, would that become relevant? And so I'll say this we're not trying to build like this, like super we were trying to build a world with privacy by default.That's what we're going for. Right. And I, I think having your own kind of platform out in Amazon or a Google, like it is privacy by default it's a system where your data isn't being harvested, where data is and being monitored at all times. It's not quite the same as maybe what a spy would want or like a criminal would want or whatever else.And maybe for those users, they probably want to keep using signal or her Maybe they'll have a key server on a, a laptop at home, but what we're trying to do is build something for the average user to get away from this world where you're just being tracked all the time, yeah. swyx: [00:31:01] A couple of questions. So when you say things like it will replace Dropbox, Facebook and so on. Yeah. So something like the how much, so as a Let's say I'm I'm I wanna, I want to start the next Dropbox. I'm going to start the next Facebook and I want to build it with the premise of let's just say the key servers or anything, and I want to interact with all these, how much control do I have on changing the schema?Cause that's, I think that's ultimately what I want, right? If I can only get what the user gives me, then my pace of development is very slow. Does that make sense? Ashoat Tevosyan: [00:31:30] Yeah, no you're absolutely right. Yeah. I mean, so in terms of a typical app, when you're developing in typical app, you have access to all this stuff that you do.Yeah. Well, this model you don't right. And so there, there's a couple kinds of ways around that. One thing that you could do is as an app developer, you could say, okay, in order to use my app, you have to friend me. On comp. So you have to take, you have to actually friend Milo corporate account, and that will allow Congress to actually say, okay, we can send data to this because we limit who you can communicate with based on your social graph.Right? So you could imagine a world where basically most apps, because the app developer just needs some logging data to be able to move forward. We'll ask you to authorize the app to actually send data out. Right. Right. And that's a trust relationship that you have to have between the app developer and the user w we want to do is to make that explicit.Right. And I also think that, depending on the application, right? So something like Dropbox, I'll say, it doesn't have to be too complicated. Like it's ultimately like this like file storage thing. And I think ideally if I was picking between an app that was maybe it was app development like finished in mostly several years back.And they just had something that works and they don't need to constantly be like getting all my data. I would probably prefer that to an app that's maybe being like, constantly evolved, but is, has this like kind of leak in there. Right. But probably depends on the app. Right. So if you imagine maybe like a social app, I probably would make that trade off in a different direction, given that, It's harder to iterate on a social app like that.So it probably depends on the application. What kind of data you're putting on the application, all this kind of stuff. But the important thing is users should be aware of it and the users should have control. Yeah. swyx: [00:33:08] So, but to be clear, the vision is that other people will build all these apps on top of calm rather than calm building all of these things.Right? Ashoat Tevosyan: [00:33:16] Yeah. So, well, so w we, we don't believe we can launch this as a platform. So, if we just throw this thing out there and just say, Hey, write apps for it. It's a hard sell because we don't have users and, users want to see apps. So we're starting by actually building out what we think of is like a killer app.And that's this like discord competitor, and the thinking there is, Discord, it's been so successful and it's Testament to this desire for private chat communities. Right. But discord is built a product for gamers, right. And it's really good for gamers. And what gamers need is like time in the moment, kind of real-time chat, right.But that's not what everyone needs. And you have so many communities. And I have so many communities on discord now that needs something different. I have all these blockchain communities, all these, get hub developer communities that probably need something that's more structured, that's more asynchronous.Right. It's more collaborative. And so. The way I look at it as this court is bound to get unbundled. There's no way in five years that we don't have like 10 discords. Right. And we're starting by basically building the anti discord exists. We're trying to take the opposite kind of angle, build something that's very complimentary to the score.And so I think there's a real need in the market for this. And I think the end of the antenna encryption is a huge plus, especially given we're targeting these initial kind of blockchain developer get hub nerds. And the hope is that these are also gonna be the first people to actually build apps in our platform.Right. But yeah, I mean, your point is correct. Like we, ultimately, this is meant to be a platform. And when we get there, like the hope is that we'll have users building apps on our platform rather than us being this like singular app developer. swyx: [00:34:37] And that's fantastic. And I often reflect on how.A lot of times people who want to build platforms end up building product first, and sometimes the product just takes off way more than that. That's cool. And Oh, which right. Like then it just proves the viability of the platform and more people will come on and build on platform, which is great for you.It just, it does spit your attention a little bit, but whenever you're pretty committed to this how much have you built already? Ashoat Tevosyan: [00:34:55] So I don't know, probably not too much. So we have an app and that happens is actually, pretty mature. It, given that I've been working on it for a long time, so we have an iOS and an Android app website, but all this key server stuff I'm talking about really has not been built out.We're just getting started on that stuff. So the, I mean, this company really got started in January. We have one employee besides me, so we're really not much of it has been built. swyx: [00:35:17] Gotcha. Can I see, because I don't think I saw it. You sent me, so all I have is this notion thing. Oh yeah.I saw the, yeah, I don't think I saw any fighter or app or anything. Okay. Ashoat Tevosyan: [00:35:28] So yeah. It's all good hub. swyx: [00:35:31] I'll share my screen just in case anyone is watching. Yeah, no, this is cool. I always like to start things for people. Oh Ashoat Tevosyan: [00:35:39] yeah. Thank you. I appreciate that. Okay. Yeah. So, so this is as it is, it's mostly like just the team collaborating on this thing.So it's not yeah we tried using that a while. Okay. That swyx: [00:35:52] since it comes and goes, I find it very useful if you commit to it. But then sometimes, stuff happens Ashoat Tevosyan: [00:35:59] Like notion mostly for that kind of like coordination stuff. swyx: [00:36:02] So basically not much to show like publicly about your there's just active development going on.Ashoat Tevosyan: [00:36:06] Yeah. I mean, so you can see the squat Cal app now, but that's what currently what this currently builds too. So yeah. It's squad call.org. There it is. But this is yeah this design has been, this is where I'm like 2018. You can see even the Android still has the Does it doesn't have the, what's it called full screen device?It looks a little old, but basically, yeah. I mean, so we have this app spot calendar. We're continuing to release the thing as squat cow, because we don't want to use a new use the name calm until we actually built out the Anton encryption layer. We want to be able to tell users right. That this is Truly private.And so we don't want to besmirch the brand with like fake end to end encryption. So we're basically continuing to use a squad count name until we get to a point where we have the antenna Christian figured out. But the Rebos under the name comm now. swyx: [00:36:50] Got it. Okay, perfect. I mean, look don't be embarrassed about it.This is what early stage is. Totally. You should be shipping stuff. You're embarrassed by it. But like what's the, so what's like the game plan for the next, the near term. Because it's, it really seems like this is going to hinge on. I guess this getting adoption within the communities that, that you want to adopt?I will say that I raised my eyebrow. When you said that you think this code will be unbundled because I think this court has a huge network effect. I don't know how to overcome it. I've. I'm invested in circle and we're trying to bridge people from this court to circle and it's just seems like discord is just way more active anyway, just cause people already in it.And so starting a new app is difficult, but then I think I said this to you in my email, like starting a new app is difficult, but if you pull it off in a, that's a hugely defensible mode. Ashoat Tevosyan: [00:37:33] Yeah. Yeah. I mean, no, you're super right. I mean, in terms of putting our investor hats on, I'd say this is the kind of thing that's like.Much less likely to hit than most startups. But if it does hit, it's like a, it's like a huge thing. Right. And I'll say this, I have deep confidence in the kind of two, two kind of principles. The first is that the world's going towards privacy, that, people are increasingly wherever their digital footprint, increasingly desire to have control over their own privacy and their own data.And that, people, I think the world is moving towards like a world where you have privacy by default. And the number two thing that I have high degree of confidence on is that the only way we can scale antenna corruption, the only way we can get to a world with privacy by default is with something like key servers.People have to have. They're one kind of server. Right? And so I hold these two things near and dear everything else like this discord idea is just an attempt to just, it just it's something that we're trying to, we're trying out. And if it doesn't work we'll try to pivot and try to find something else in terms of like, why I'm optimistic about it.I'll S I'll say, there's a whole thing I gave the whole spiel. I gave you where I look at this as NC. Discord like being hacked in into a lot of use cases that really just wasn't built for. And I think in particular, the community is I've been talking about these like blockchain developers and these GitHub people.They're obsessed with this kind of vision of decentralized community. Like they're already in our cult of having control of their data, it rather than deferring that to some corporation. Right. So I think there's a huge appeal there. And I'm hoping those two things we'll work together.The other side of it is, we consider three other angles of how to build this thing and they have some limitations that the, this court approach doesn't one of the biggest advantages of the discord approach is that only admins need to set up a key server. Right. Cause setting up a key server, it's like a pretty high friction process.I talked about it earlier, either have a spare laptop or you deploy something to the cloud and maybe your super nerd is going to be down to do that initially. But the average user is like just one installed app, and so with this kind of discord approach, only the admin needs to do it.And the average user just sets it up on their phone, just like any other kind of app. And there's one of thing. Oh yeah. The social layer. So basically. Another big advantage of this or this kind of discord approach, as opposed to some of the other projects we've talked about.So ultimately antenna corruption, it's it's a social thing. It's about enabling to users to be able to communicate with each other, without having some intermediary have access to that data. Right? So in order for us to be able to do that, to be able to guarantee to a user that any app that they install on our platform is end to end encrypted for us to make that guarantee.We need to control all aspects of that app and we have to control where it runs and we can't let the app developer have access to internet. Right. And that means we have to provide the social air and for us to be able to do that when you can bootstrap a social craft. And so it's another kind of big advantage of this discord approach that a lot of the other purchases just don't have.But yeah, I mean, I'll tell you're totally right. Like the most likely reason this thing fails is we fail to get traction with our app. Yeah, it's swyx: [00:40:11] cool. Yeah. I mean this, I think I love the ambition. I love the mission. And you're totally right to focus in on, on, I guess, your words, the cult of people who really wants to control the data and have the technical competency to set this thing up, because I think people want privacy first, but the.Every time you trade off UX that's a large chunk of the cock published and you just shut off. So it's a it's a challenging thing. What can, what can I, you reached out to me talking about introductions. I'm probably not going to invest at this stage because I don't really understand this as, as well as I should, but I mean, I'm really impressed by your storytelling and your background.And I mean, I think this is a. It's one of those things where if it goes well, it goes really well. And I'm always open to ideas like that. But who can I introduce you to what kind of help are you looking for? Yeah. Ashoat Tevosyan: [00:40:55] So the number one thing I'm trying to figure out right now is hiring.So, we have me, we have one employee, but he's straight out of college. And we have a team in Poland. But like really I need to find kind of two personas. One is like kind of CTO, character, 10 X engineer. He replaced me. Right. And I'm doing all this code review, like right before this call, I was doing code review.And I just I don't have time to do all this stuff. And so I need to find someone who can build out the first version of all this key server tech and own that. And then the other kind of side, I need to find somebody who's like a design product guru, somebody who can like.Own this product definition. Cause I have some experience with product. I spent my life working on social products, but in terms of like design, I'm like, I can I'm not good at designing things super well. So I need somebody who can partner with me on that and also a lot of other, a lot of their hats that need to be worn stuff like kind of community manager, UX researcher.So the number one way you could help me is if you know anybody who could be a good fit for either of these roles, or if no one comes to mind, if people who might know people. So second orders. So whoever you could think of who, who might know somebody. swyx: [00:41:56] And do you have you have you applied to any of the accelerators, like the YCS of the world, but th there can be more than that.Right? So the Techstars is also an Ashoat Tevosyan: [00:42:04] option. Yeah. So, so I spent a good amount of time considering some accelerators. I ultimately decided against all of them right now, a couple kinds of concerns, one with this whole kind of like pandemic situation. Like they're all trying to do remote and I just don't know if I can really get to that level of confidence about somebody who just like from zoom, and I don't know if I that the magic, the collaborative magic is it going to, is going to spark? And before we go into these, they always ask for 7% and 7%. I mean, I've already raised some money. I don't think my investors are super, would be super excited about that.And I also myself would have to really justify that pretty strongly and swyx: [00:42:38] redacting some details about fundraising here, per request. Ashoat Tevosyan: [00:42:41] So, yeah, so I'd say honestly, fundraising quite well. I think it's Testament to, this is like a moment for encryption right now. And I think there's a lot of money floating around.And I think I've gotten pretty good at the storytelling and then the selling, but the part that I'm really struggling on is hiring, which is weird because, I come from a technical background, but I've already tried all my friends and I've tried their friends and yeah. So whatever you can do to help there I'd really appreciate it.swyx: [00:43:03] Yeah. I'll keep it. I'll keep this in mind. I don't know. One comes to mind like right now I, I have, well where I work at Temporal and we're in a process of trying to hire a design lead ourselves. Ashoat Tevosyan: [00:43:15] Yeah, it's hard, but swyx: [00:43:16] This is a very different opportunity and we can both co-exist and I'll just make sure to route people to you when their sort of profile matches up I was also going to suggest.I didn't know. I didn't know you're this far advanced in the fundraising because I was going to suggest talking to people like Brian Acton or Mike Krieger to invest. Cause they're pretty Ashoat Tevosyan: [00:43:31] active angels. I would love to talk to either of those people. Yeah, literally both, both those people are people that I would love to get connected to and haven't been able to find like an, like a, Oh yeah.Okay. swyx: [00:43:42] So. Yeah, Mike is a co- investor in Supabase. So, what I should do is I should introduce you to, this is going to be a w because I'm two degrees separation from him. So, I'll introduce you to Paul cobblestone, who is the CEO of super base who Mike invested in. And so if he can probably get you that warm intro Mike seems like he's just.Investing in everything. So I think he'll at least take a call from you just because of your background and this is something that he's interested in Brian and I have zero connections to, I'm just, I just think that he's very interested in it. Ashoat Tevosyan: [00:44:11] Yeah, exactly. No. Brian Acton obviously makes a lot of sense.And yeah. So yeah, if I could find anybody from that WhatsApp team would be amazing. Yeah. Yeah. Also mostly Marlin spike. If you know anyone who knows Moxie. swyx: [00:44:25] Moxie. I don't know, Ashoat Tevosyan: [00:44:25] Moxie. Oh, sorry. This the founder of signal. swyx: [00:44:28] Okay. Got it. Is this is how far out of death. I am like, I'm not super close.I just, I know it's a thing and I know some people tend to initially but cool. No, no one comes to mind. don't want to over promise you, but I thought this was really compelling. And I thought, at least the least I can do is have this, have your story straight. So when I tell it to people at least get to help you pitch these things and hopefully send people your way.I think you're, I think you were working on really cool stuff. I mean, that's, I'm a little bit jealous cause you have the space to experiment, and you're passionate about this. And, even if this immediate thing doesn't work out you'll find something else that they clicked.So this is pretty Ashoat Tevosyan: [00:45:02] cool. Awesome. Yeah. Thanks. I appreciate the vote of confidence.
Protocolo intercambio de clave diffie-hellman, cuanto tarda transferencia de Bitcoin, Plataformas DeFi de Lending
החלק השלישי והאחרון בסדרת פרקי "תולדות ההצפנה" שלנו. בפרק זה נגיע לשיטות ההצפנה של העידן המודרני. תחילה ה-DES וה-AES הוותיקות יחסית, לאחר מכן השיטה המהפכנית שהגו Diffie ו-Hellman להחלפת מסרים מוצפנים ללא צורך בשיתוף מוקדם של הצופן בין הצדדים, ואז נגיע לשיטות העדכניות ביותר: RSA שבו אנו משתמשים עד היום, PGP שהנגיש לנו את RSA, ומה צופן לנו העתיד בתחום ההצפנה ופריצתה. לא להילחץ ולהתבלבל מראשי התיבות! הכל מוסבר בפרק בצורה נפלאה, ואין צורך להיות איש תוכנה כדי להבין את הדברים. לכבוד סיומה של סדרה זו יצרנו מדריך פרקים כאן -> https://www.facebook.com/OutOfMemoryPodcast/posts/2560178044019849 מלבד סקירת תוכן, המדריך כולל מראי מקומות למושגים ולאנשים השונים שהזכרנו, וכן לינקים לספרים עליהם התבססה הסדרה, לכל מי שמעוניין להרחיב ולהעמיק.
Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is scraping the surface of cryptography. Cryptography is derived from the Greek words kryptos, which stands for hidden and grafein, which stands for to write. Through history, cryptography has meant the process of concealing the contents of a message from all except those who know the key. Dating back to 1900 BC in Egypt and Julius Caesar using substitution cyphers, encryption used similar techniques for thousands of years, until a little before World War II. Vigenere designed the first known cipher thatused an encryption key in the 16th century. Since then with most encryption, you convert the contents, known as plaintext, into encrypted information that's otherwise unintelligible, known as cipher text. The cypher is a pair of algorithms - one to encrypt, the other to decrypt. Those processes are done by use of a key. Encryption has been used throughout the ages to hide messages. Thomas Jefferson built a wheel cypher. The order of the disks you put in the wheel was the key and you would provide a message, line the wheels up and it would convert the message into cypher text. You would tell the key to the person on the other end, they would put in the cypher text and out would pop the message. That was 1795 era encryption and is synonymous with what we call symmetrical key cryptography, which was independently invented by Etienne Bazeries and used well into the 1900s by the US Army. The Hebern rotor machine in the 19th century gave us an electro-mechanical version of the wheel cypher and then everything changed in encryption with the introduction of the Enigma Machine, which used different rotors placed into a machine and turned at different speeds based on the settings of those rotors. The innovations that came out of breaking that code and hiding the messages being sent by the Allies kickstarted the modern age of encryption. Most cryptographic techniques rely heavily on the exchange of cryptographic keys. Symmetric-key cryptography refers to encryption methods where both senders and receivers of data share the same key and data is encrypted and decrypted with algorithms based on those keys. The modern study of symmetric-key ciphers revolves around block ciphers and stream ciphers and how these ciphers are applied. Block ciphers take a block of plaintext and a key, then output a block of ciphertext of the same size. DES and AES are block ciphers. AES, also called Rijndael, is a designated cryptographic standard by the US government. AES usually uses a key size of 128, 192 or 256 bits. DES is no longer an approved method of encryption triple-DES, its variant, remains popular. Triple-DES uses three 56-bit DES keys and is used across a wide range of applications from ATM encryption to e-mail privacy and secure remote access. Many other block ciphers have been designed and released, with considerable variation in quality. Stream ciphers create an arbitrarily long stream of key material, which is combined with a plaintext bit by bit or character by character, somewhat like the one-time pad encryption technique. In a stream cipher, the output stream is based on an internal state, which changes as the cipher operates. That state's change is controlled by the key, and, in some stream ciphers, by the plaintext stream as well. RC4 is an example of a well-known stream cipher. Cryptographic hash functions do not use keys but take data and output a short, fixed length hash in a one-way function. For good hashing algorithms, collisions (two plaintexts which produce the same hash) are extremely difficult to find, although they do happen. Symmetric-key cryptosystems typically use the same key for encryption and decryption. A disadvantage of symmetric ciphers is that a complicated key management system is necessary to use them securely. Each distinct pair of communicating parties must share a different key. The number of keys required increases with the number of network members. This requires very complex key management schemes in large networks. It is also difficult to establish a secret key exchange between two communicating parties when a secure channel doesn't already exist between them. You can think of modern cryptography in computers as beginning with DES, or the Data Encryption Standard, us a 56-bit symmetric-key algorithm developed by IBM and published in 1975, with some tweaks here and there from the US National Security Agency. In 1977, Whitfield Diffie and Martin Hellman claimed they could build a machine for $20 million dollars that could find a DES key in one day. As computers get faster, the price goes down as does the time to crack the key. Diffie and Hellman are considered the inventors of public-key cryptography, or asymmetric key cryptography, which they proposed in 1976. With public key encryption, two different but mathematically related keys are used: a public key and a private key. A public key system is constructed so that calculation of the private key is computationally infeasible from knowledge of the public key, even though they are necessarily related. Instead, both keys are generated secretly, as an interrelated pair. In public-key cryptosystems, the public key may be freely distributed, while its paired private key must remain secret. The public key is typically used for encryption, while the private or secret key is used for decryption. Diffie and Hellman showed that public-key cryptography was possible by presenting the Diffie-Hellman key exchange protocol. The next year, Ron Rivest, Adi Shamir and Leonard Adleman developed the RSA encryption algorithm at MIT and founded RSA Data Security a few years later in 1982. Later, it became publicly known that asymmetric cryptography had been invented by James H. Ellis at GCHQ, a British intelligence organization and that both the Diffie-Hellman and RSA algorithms had been previously developed in 1970 and were initially called “non-secret encryption.” Apparently Ellis got the idea reading a bell labs paper about encrypting voice communication from World War II. Just to connect some dots here, Alan Turing, who broke the Enigma encryption, visited the proposed author of that paper, Shannon, in 1943. This shouldn't take anything away from Shannon, who was a brilliant mathematical genius in his own right, and got to see Gödel, Einstein, and others at Princeton. Random note: he invented wearables to help people cheat at roulette. Computer nerds have been trying leverage their mad skills to cheat at gambling for a long time. By the way, he also tried to cheat at, er, I mean, program chess very early on, noting that 10 to the 120th power was the game-tree complexity of chess and wrote a paper on it. Of course someone who does those things as a hobby would be widely recognized as the father of informational theory. RSA grew throughout the 80s and 90s and in 1995, they spun off a company called VeriSign, who handled patent agreements for the RSA technology until the patents wore out, er, I mean expired. RSA Security was acquired by EMC Corporation in 2006 for $2.1 billion and was a division of EMC until EMC was acquired by Dell in 2016. They also served as a CA - that business unit was sold in 2010 to Symantec for $1.28B. RSA has made a number of acquisitions and spun other businesses off over the years, helping them get into more biometric encryption options and other businesses. Over time the 56 bit key size of DES was too small and it was followed up by Triple-DES in 1998. And Advanced Encryption Standard, or AES, also in 1998. Diffie-Hellman and RSA, in addition to being the first public examples of high quality public-key cryptosystems have been amongst the most widely used. In addition to encryption, public-key cryptography can be used to implement digital signature schemes. A digital signature is somewhat like an ordinary signature; they have the characteristic that they are easy for a user to produce, but difficult for anyone else to forge. Digital signatures can also be permanently tied to the content of the message being signed as they cannot be moved from one document to another as any attempt will be detectable. In digital signature schemes, there are two algorithms: one for signing, in which a secret key is used to process the message (or a hash of the message or both), and one for verification, in which the matching public key is used with the message to check the validity of the signature. RSA and DSA are two of the most popular digital signature schemes. Digital signatures are central to the operation of public key infrastructures and to many network security schemes (SSL/TLS, many VPNs, etc). Digital signatures provide users with the ability to verify the integrity of the message, thus allowing for non-repudiation of the communication. Public-key algorithms are most often based on the computational complexity of hard problems, often from number theory. The hardness of RSA is related to the integer factorization problem, while Diffie-Hellman and DSA are related to the discrete logarithm problem. More recently, elliptic curve cryptography has developed in which security is based on number theoretic problems involving elliptic curves. Because of the complexity of the underlying problems, most public-key algorithms involve operations such as modular multiplication and exponentiation, which are much more computationally expensive than the techniques used in most block ciphers, especially with typical key sizes. As a result, public-key cryptosystems are commonly hybrid systems, in which a fast symmetric-key encryption algorithm is used for the message itself, while the relevant symmetric key is sent with the message, but encrypted using a public-key algorithm. Hybrid signature schemes are often used, in which a cryptographic hash function is computed, and only the resulting hash is digitally signed. OpenSSL is a software library that most applications use to access the various encryption mechanisms supported by the operating systems. OpenSSL supports Diffie-Hellman and various versions of RSA, MD5, AES, Base, sha, DES, cast and rc. OpenSSL allows you to create ciphers, decrypt information and set the various parameters required to encrypt and decrypt data. There are so many of these algorithms because people break them and then a new person has to come along and invent one and then version it, then add more bits to it, etc. At this point, I personally assume that all encryption systems can be broken. This might mean that the system is broken while encrypting, or the algorithm itself is broken once encrypted. A great example would be an accidental programming mistake allowing a password to be put into the password hint rather than in the password. Most flaws aren't as simple as that. Although Kerckhoffs's principle teaches us that the secrecy of your message should depend on the secrecy of the key, and not on the secrecy of the system used to encrypt the message. Some flaws are with the algorithms themselves, though. At this point most of those are public and security without a password or private key they just take too long to decrypt to be worth anything once decrypted. This doesn't mean we don't encrypt things, it just means that in addition to encryption we now add another factor to that security. But we'll leave the history of two-factor security to another episode. Finally, RSA made a lot of money because they used ciphers that were publicly reviewed and established as a standard. Public review of various technological innovations allows for commentary and making it better. Today, you can trust most encryption systems because due to that process, it costs more to decrypt what you're sending over the wire than what is being sent is worth. In other words, collaboration trumps secrecy.
Derek and Zak confirm they are talking to each other using the Diffie-Hellman protocol. Zak… Read the postEncryption: Diffie-Hellman & RSA The post Encryption: Diffie-Hellman & RSA appeared first on The Hyperfine.
Derek and Zak confirm they are talking to each other using the Diffie-Hellman protocol. Zak… Read the postEncryption: Diffie-Hellman & RSA The post Encryption: Diffie-Hellman & RSA appeared first on The Hyperfine.
Derek and Zak confirm they are talking to each other using the Diffie-Hellman protocol. Zak… Read the postEncryption: Diffie-Hellman & RSA The post Encryption: Diffie-Hellman & RSA appeared first on The Hyperfine.
Beschreibung: In dieser Folge unterhalten wir uns über Wireguard, ein neues VPN-Protokoll das von Jason A. Donenfeld designt und entwickelt wurde. Auch wenn wir versuchen objektiv über das VPN-Protokoll zu sprechen, können wir unsere Begeisterung schwer verbergen. Ein komplettes VPN-Protokoll in weniger als 4000 Zeilen Code und basierend auf moderner Kryptografie. Zusätzlich ist Wireguard so aufgebaut, dass keine dynamischen Speicherallozierung notwendig ist und auch kein Parsing. Shownotes: Homepage von Wireguard Whitepaper von Wireguard WP: Virtual Private Network Linus Torvalds über Wireguard auf der LKML Paper: A Cryptographic Evaluation of IPsec von Ferguson & Schneier Schneier on Security WP: Niels Ferguson Slides: On the Possibility of a Back Door in the NIST SP800-90 Dual EC PRNG New York Times provides new details about NSA backdoor in crypto spec Homepage von Jason A. Donenfeld (zx2c4) Pass: the standard unix password manager Liste von Exploits von zx2c4 The padata parallel execution mechanism Erste Performance-Tests von Wireguard Reddit: WireGuard benchmark between two servers with 10 Gb ethernet FriVPN: Multithreaded OpenVPN client (WIP) von Hunz Curve25519: A state-of-the-art Diffie-Hellman function BLAKE2: simpler, smaller, fast as MD5 The ChaCha family of stream ciphers The Poly1305-AES message-authentication code Formal Verification of the WireGuard Protocol von J. Donenfeld und K. Milner TAI64N Zeitstempel von Daniel J. Bernstein Security Analysis of WireGuard (MIT 6.857 Final Project) von Andrew He, Baula Xu und Jerry Wu Noise Protocol Framework Vortrag von Trevor Perrin über das Noise Protocol auf dem 34C3 WP: Diffie–Hellman key exchange Fun with NULL pointers, part 1 Mosh: the mobile shell Mullvad, Schwedischer VPN Provider der auch Wireguard Server betreibt Wireguard Demo Server
In today's podcast, we hear that Special Counsel Mueller has secured an indictment of twelve Russian intelligence officers for hacking during the 2016 US presidential elections. Ukraine finds VPNFilter in a water treatment facility. Comment spam returns. Speculative execution issues. Mobile-device-management tool used against smartphone users in India. The US Army directly commissions two cyber operators—congratulations, First Lieutenants. Ben Yelin from UMD CHHS on California’s consumer privacy ballot measure. Guest is Martin Hellman, professor emeritus at Stanford University and known for his work on Diffie–Hellman key exchange. His new book is A New Map for Relationships: Creating True Love at Home and Peace on the Planet.
In dieser Episode befassen sich die Experten Sven und Stefan mit dem Diffie-Hellman Verfahren und erklären/diskutieren an einem lebensnahen Beispiel, welches mit einem Anruf beim Notarzt endet, wie dieses funktioniert. Zuvor jedoch wie immer die Datenverluste, welche seit der letzten Folge bekannt wurden und die Nachrichten. Aufgrund seiner Star-Allüren und seiner maßlosen Selbstüberschätzung gibt es auch noch eine Richtigstellung zum Dropbox-Leak, wodurch Stefan wieder zurück auf den Boden der Tatsachen kommt und einsieht, dass er niemals berühmt werden wird. Disclaimer In diesem Podcast werden Techniken oder Hardware vorgestellt, die geeignet sind, externe Geräte anzugreifen. Dies geschieht ausschließlich zu Bildungszwecken, denn nur, wenn man die Angriffstechniken kennt, kann man sich effektiv davor schützen. Denkt immer daran, diese Techniken oder Hardware nur bei Geräten anzuwenden, deren Eigner oder Nutzer das erlaubt haben.Der unerlaubte Zugriff auf fremde Infrastruktur ist strafbar (In Deutschland §202a, §202b, §202c StGB).
Second round of ZFS improvements in FreeBSD, Postgres finds that non-FreeBSD/non-Illumos systems are corrupting data, interview with Kevin Bowling, BSDCan list of talks, and cryptographic right answers. Headlines [Other big ZFS improvements you might have missed] 9075 Improve ZFS pool import/load process and corrupted pool recovery One of the first tasks during the pool load process is to parse a config provided from userland that describes what devices the pool is composed of. A vdev tree is generated from that config, and then all the vdevs are opened. The Meta Object Set (MOS) of the pool is accessed, and several metadata objects that are necessary to load the pool are read. The exact configuration of the pool is also stored inside the MOS. Since the configuration provided from userland is external and might not accurately describe the vdev tree of the pool at the txg that is being loaded, it cannot be relied upon to safely operate the pool. For that reason, the configuration in the MOS is read early on. In the past, the two configurations were compared together and if there was a mismatch then the load process was aborted and an error was returned. The latter was a good way to ensure a pool does not get corrupted, however it made the pool load process needlessly fragile in cases where the vdev configuration changed or the userland configuration was outdated. Since the MOS is stored in 3 copies, the configuration provided by userland doesn't have to be perfect in order to read its contents. Hence, a new approach has been adopted: The pool is first opened with the untrusted userland configuration just so that the real configuration can be read from the MOS. The trusted MOS configuration is then used to generate a new vdev tree and the pool is re-opened. When the pool is opened with an untrusted configuration, writes are disabled to avoid accidentally damaging it. During reads, some sanity checks are performed on block pointers to see if each DVA points to a known vdev; when the configuration is untrusted, instead of panicking the system if those checks fail we simply avoid issuing reads to the invalid DVAs. This new two-step pool load process now allows rewinding pools across vdev tree changes such as device replacement, addition, etc. Loading a pool from an external config file in a clustering environment also becomes much safer now since the pool will import even if the config is outdated and didn't, for instance, register a recent device addition. With this code in place, it became relatively easy to implement a long-sought-after feature: the ability to import a pool with missing top level (i.e. non-redundant) devices. Note that since this almost guarantees some loss Of data, this feature is for now restricted to a read-only import. 7614 zfs device evacuation/removal This project allows top-level vdevs to be removed from the storage pool with “zpool remove”, reducing the total amount of storage in the pool. This operation copies all allocated regions of the device to be removed onto other devices, recording the mapping from old to new location. After the removal is complete, read and free operations to the removed (now “indirect”) vdev must be remapped and performed at the new location on disk. The indirect mapping table is kept in memory whenever the pool is loaded, so there is minimal performance overhead when doing operations on the indirect vdev. The size of the in-memory mapping table will be reduced when its entries become “obsolete” because they are no longer used by any block pointers in the pool. An entry becomes obsolete when all the blocks that use it are freed. An entry can also become obsolete when all the snapshots that reference it are deleted, and the block pointers that reference it have been “remapped” in all filesystems/zvols (and clones). Whenever an indirect block is written, all the block pointers in it will be “remapped” to their new (concrete) locations if possible. This process can be accelerated by using the “zfs remap” command to proactively rewrite all indirect blocks that reference indirect (removed) vdevs. Note that when a device is removed, we do not verify the checksum of the data that is copied. This makes the process much faster, but if it were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be possible to copy the wrong data, when we have the correct data on e.g. the other side of the mirror. Therefore, mirror and raidz devices can not be removed. You can use ‘zpool detach’ to downgrade a mirror to a single top-level device, so that you can then remove it 7446 zpool create should support efi system partition This one was not actually merged into FreeBSD, as it doesn’t apply currently, but I would like to switch the way FreeBSD deals with full disks to be closer to IllumOS to make automatic spare replacement a hands-off operation. Since we support whole-disk configuration for boot pool, we also will need whole disk support with UEFI boot and for this, zpool create should create efi-system partition. I have borrowed the idea from oracle solaris, and introducing zpool create -B switch to provide an way to specify that boot partition should be created. However, there is still an question, how big should the system partition be. For time being, I have set default size 256MB (thats minimum size for FAT32 with 4k blocks). To support custom size, the set on creation "bootsize" property is created and so the custom size can be set as: zpool create -B -o bootsize=34MB rpool c0t0d0. After the pool is created, the "bootsize" property is read only. When -B switch is not used, the bootsize defaults to 0 and is shown in zpool get output with no value. Older zfs/zpool implementations can ignore this property. **Digital Ocean** PostgreSQL developers find that every operating system other than FreeBSD and IllumOS might corrupt your data Some time ago I ran into an issue where a user encountered data corruption after a storage error. PostgreSQL played a part in that corruption by allowing checkpoint what should've been a fatal error. TL;DR: Pg should PANIC on fsync() EIO return. Retrying fsync() is not OK at least on Linux. When fsync() returns success it means "all writes since the last fsync have hit disk" but we assume it means "all writes since the last SUCCESSFUL fsync have hit disk". Pg wrote some blocks, which went to OS dirty buffers for writeback. Writeback failed due to an underlying storage error. The block I/O layer and XFS marked the writeback page as failed (ASEIO), but had no way to tell the app about the failure. When Pg called fsync() on the FD during the next checkpoint, fsync() returned EIO because of the flagged page, to tell Pg that a previous async write failed. Pg treated the checkpoint as failed and didn't advance the redo start position in the control file. + All good so far. But then we retried the checkpoint, which retried the fsync(). The retry succeeded, because the prior fsync() *cleared the ASEIO bad page flag*. The write never made it to disk, but we completed the checkpoint, and merrily carried on our way. Whoops, data loss. The clear-error-and-continue behaviour of fsync is not documented as far as I can tell. Nor is fsync() returning EIO unless you have a very new linux man-pages with the patch I wrote to add it. But from what I can see in the POSIX standard we are not given any guarantees about what happens on fsync() failure at all, so we're probably wrong to assume that retrying fsync() is safe. We already PANIC on fsync() failure for WAL segments. We just need to do the same for data forks at least for EIO. This isn't as bad as it seems because AFAICS fsync only returns EIO in cases where we should be stopping the world anyway, and many FSes will do that for us. + Upon further looking, it turns out it is not just Linux brain damage: Apparently I was too optimistic. I had looked only at FreeBSD, which keeps the page around and dirties it so we can retry, but the other BSDs apparently don't (FreeBSD changed that in 1999). From what I can tell from the sources below, we have: Linux, OpenBSD, NetBSD: retrying fsync() after EIO lies FreeBSD, Illumos: retrying fsync() after EIO tells the truth + NetBSD PR to solve the issues + I/O errors are not reported back to fsync at all. + Write errors during genfs_putpages that fail for any reason other than ENOMEM cause the data to be semi-silently discarded. + It appears that UVM pages are marked clean when they're selected to be written out, not after the write succeeds; so there are a bunch of potential races when writes fail. + It appears that write errors for buffercache buffers are semi-silently discarded as well. Interview - Kevin Bowling: Senior Manager Engineering of LimeLight Networks - kbowling@llnw.com / @kevinbowling1 BR: How did you first get introduced to UNIX and BSD? AJ: What got you started contributing to an open source project? BR: What sorts of things have you worked on it the past? AJ: Tell us a bit about LimeLight and how they use FreeBSD. BR: What are the biggest advantages of FreeBSD for LimeLight? AJ: What could FreeBSD do better that would benefit LimeLight? BR: What has LimeLight given back to FreeBSD? AJ: What have you been working on more recently? BR: What do you find to be the most valuable part of open source? AJ: Where do you think the most improvement in open source is needed? BR: Tell us a bit about your computing history collection. What are your three favourite pieces? AJ: How do you keep motivated to work on Open Source? BR: What do you do for fun? AJ: Anything else you want to mention? News Roundup BSDCan 2018 Selected Talks The schedule for BSDCan is up Lots of interesting content, we are looking forward to it We hope to see lots of you there. Make sure you come introduce yourselves to us. Don’t be shy. Remember, if this is your first BSDCan, checkout the newbie session on Thursday night. It’ll help you get to know a few people so you have someone you can ask for guidance. Also, check out the hallway track, the tables, and come to the hacker lounge. iXsystems Cryptographic Right Answers Crypto can be confusing. We all know we shouldn’t roll our own, but what should we use? Well, some developers have tried to answer that question over the years, keeping an updated list of “Right Answers” 2009: Colin Percival of FreeBSD 2015: Thomas H. Ptacek 2018: Latacora A consultancy that provides “Retained security teams for startups”, where Thomas Ptacek works. We’re less interested in empowering developers and a lot more pessimistic about the prospects of getting this stuff right. There are, in the literature and in the most sophisticated modern systems, “better” answers for many of these items. If you’re building for low-footprint embedded systems, you can use STROBE and a sound, modern, authenticated encryption stack entirely out of a single SHA-3-like sponge constructions. You can use NOISE to build a secure transport protocol with its own AKE. Speaking of AKEs, there are, like, 30 different password AKEs you could choose from. But if you’re a developer and not a cryptography engineer, you shouldn’t do any of that. You should keep things simple and conventional and easy to analyze; “boring”, as the Google TLS people would say. Cryptographic Right Answers Encrypting Data Percival, 2009: AES-CTR with HMAC. Ptacek, 2015: (1) NaCl/libsodium’s default, (2) ChaCha20-Poly1305, or (3) AES-GCM. Latacora, 2018: KMS or XSalsa20+Poly1305 Symmetric key length Percival, 2009: Use 256-bit keys. Ptacek, 2015: Use 256-bit keys. Latacora, 2018: Go ahead and use 256 bit keys. Symmetric “Signatures” Percival, 2009: Use HMAC. Ptacek, 2015: Yep, use HMAC. Latacora, 2018: Still HMAC. Hashing algorithm Percival, 2009: Use SHA256 (SHA-2). Ptacek, 2015: Use SHA-2. Latacora, 2018: Still SHA-2. Random IDs Percival, 2009: Use 256-bit random numbers. Ptacek, 2015: Use 256-bit random numbers. Latacora, 2018: Use 256-bit random numbers. Password handling Percival, 2009: scrypt or PBKDF2. Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2. Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. Asymmetric encryption Percival, 2009: Use RSAES-OAEP with SHA256 and MGF1+SHA256 bzzrt pop ffssssssst exponent 65537. Ptacek, 2015: Use NaCl/libsodium (box / cryptobox). Latacora, 2018: Use Nacl/libsodium (box / cryptobox). Asymmetric signatures Percival, 2009: Use RSASSA-PSS with SHA256 then MGF1+SHA256 in tricolor systemic silicate orientation. Ptacek, 2015: Use Nacl, Ed25519, or RFC6979. Latacora, 2018: Use Nacl or Ed25519. Diffie-Hellman Percival, 2009: Operate over the 2048-bit Group #14 with a generator of 2. Ptacek, 2015: Probably still DH-2048, or Nacl. Latacora, 2018: Probably nothing. Or use Curve25519. Website security Percival, 2009: Use OpenSSL. Ptacek, 2015: Remains: OpenSSL, or BoringSSL if you can. Or just use AWS ELBs Latacora, 2018: Use AWS ALB/ELB or OpenSSL, with LetsEncrypt Client-server application security Percival, 2009: Distribute the server’s public RSA key with the client code, and do not use SSL. Ptacek, 2015: Use OpenSSL, or BoringSSL if you can. Or just use AWS ELBs Latacora, 2018: Use AWS ALB/ELB or OpenSSL, with LetsEncrypt Online backups Percival, 2009: Use Tarsnap. Ptacek, 2015: Use Tarsnap. Latacora, 2018: Store PMAC-SIV-encrypted arc files to S3 and save fingerprints of your backups to an ERC20-compatible blockchain. Just kidding. You should still use Tarsnap. Seriously though, use Tarsnap. Adding IPv6 to an existing server I am adding IPv6 addresses to each of my servers. This post assumes the server is up and running FreeBSD 11.1 and you already have an IPv6 address block. This does not cover the creation of an IPv6 tunnel, such as that provided by HE.net. This assumes native IPv6. In this post, I am using the IPv6 addresses from the IPv6 Address Prefix Reserved for Documentation (i.e. 2001:DB8::/32). You should use your own addresses. The IPv6 block I have been assigned is 2001:DB8:1001:8d00/64. I added this to /etc/rc.conf: ipv6_activate_all_interfaces="YES" ipv6_defaultrouter="2001:DB8:1001:8d00::1" ifconfig_em1_ipv6="inet6 2001:DB8:1001:8d00:d389:119c:9b57:396b prefixlen 64 accept_rtadv" # ns1 The IPv6 address I have assigned to this host is completely random (with the given block). I found a random IPv6 address generator and used it to select d389:119c:9b57:396b as the address for this service within my address block. I don’t have the reference, but I did read that randomly selecting addresses within your block is a better approach. In order to invoke these changes without rebooting, I issued these commands: ``` [dan@tallboy:~] $ sudo ifconfig em1 inet6 2001:DB8:1001:8d00:d389:119c:9b57:396b prefixlen 64 accept_rtadv [dan@tallboy:~] $ [dan@tallboy:~] $ sudo route add -inet6 default 2001:DB8:1001:8d00::1 add net default: gateway 2001:DB8:1001:8d00::1 ``` If you do the route add first, you will get this error: [dan@tallboy:~] $ sudo route add -inet6 default 2001:DB8:1001:8d00::1 route: writing to routing socket: Network is unreachable add net default: gateway 2001:DB8:1001:8d00::1 fib 0: Network is unreachable Beastie Bits Ghost in the Shell – Part 1 Enabling compression on ZFS - a practical example Modern and secure DevOps on FreeBSD (Goran Mekić) LibreSSL 2.7.0 Released zrepl version 0.0.3 is out! [ZFS User Conference](http://zfs.datto.com/] Tarsnap Feedback/Questions Benjamin - BSD Personal Mailserver Warren - ZFS volume size limit (show #233) Lars - AFRINIC Brad - OpenZFS vs OracleZFS Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
In this weeks episode we are lucky to be joined again by Scott Arciszewski. We start off the show by discussing the difference between Symmetric and Asymmetric Encryption, what Authenticated Encryption is and how secret-keys are exchanged using Diffie-Hellman. From here, we move on to highlight how Elliptic-curve cryptography works, what DNSCrypt is and why prime numbers are so important in cryptography. Finally, we touch upon multi-factor authentication, how one time passwords work, SMS vulnerabilities and how to manage password recovery.
What does a quantum computer look like? What does the future of cyber security hold? We sit down with Lee Barford to discuss. Hosted by Daniel Bogdanoff and Mike Hoffman, EEs Talk Tech is a twice-monthly engineering podcast discussing tech trends and industry news from an electrical engineer's perspective
Intro / Outro I Do Believe I've Had Enough by Zephaniah And The 18 Wheelers http://freemusicarchive.org/music/Zephaniah_And_The_18_Wheelers/Live_On_WFMUs_Honky_Tonk_Radio_Girl_Program_with_Becky_11316/Zephaniah_And_The_18_Wheelers_02_I_Do_Believe_Ive_Had_Enough Big 4 of the top security and privacy conferences: S&P ("Oakland"), NDSS, CCS and USENIX Security. Наука не делается самостоятельно, a нужно учиться у передовых исследований, как они интегрируются с практикой, понимать их уровень, и себя показывать. По-этому, для того кто первый с украинским affiliation опубликует статью на этих конференциях - с меня можно пообещать "коньяк" :) The Network and Distributed System Security Symposium (NDSS) 2017 by Internet Society - http://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017 > From the keynote speech by J. Alex Halderman: "Want to Know if the Election was Hacked? Look at the Ballots" - https://medium.com/@jhalderm/want-to-know-if-the-election-was-hacked-look-at-the-ballots-c61a6113b0ba "Securing Digital Democracy" course - https://www.coursera.org/learn/digital-democracy Video - https://www.youtube.com/watch?v=Snoo6CXiyWU&feature=youtu.be > Web Security section: "(Cross-)Browser Fingerprinting via OS and Hardware Level Features" by Yinzhi Cao et al. - https://www.internetsociety.org/doc/cross-browser-fingerprinting-os-and-hardware-level-features Websites to test your browser and device fingerprint: https://panopticlick.eff.org https://amiunique.org http://uniquemachine.org (now, cross-browser!) "Fake Co-visitation Injection Attacks to Recommender Systems" by Guolei Yang et al. - https://www.internetsociety.org/doc/fake-co-visitation-injection-attacks-recommender-systems > User Authentication section: "Cracking Android Pattern Lock in Five Attempts" by Guixin Ye at el. - https://www.internetsociety.org/doc/cracking-android-pattern-lock-five-attempts "Towards Implicit Visual Memory-Based Authentication" by - https://www.internetsociety.org/doc/towards-implicit-visual-memory-based-authentication > TLS et al. (several papers on Diffie-Hellman and more) "The Security Impact of HTTPS Interception" by Zakir Durumeric et al. - https://www.internetsociety.org/doc/security-impact-https-interception "WireGuard: Next Generation Kernel Network Tunnel" by Claude Castelluccia et al. - https://www.internetsociety.org/doc/wireguard-next-generation-kernel-network-tunnel (by a single author, Jason Donenfeld!) More on WireGuard: https://fosdem.org/2017/schedule/event/wireguard/ https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-2016 https://www.wireguard.io > On Tor: "The Effect of DNS on Tor's Anonymity" by Benjamin Greschbach et al. - https://www.internetsociety.org/doc/e-effect-dns-tors-anonymity "Avoiding The Man on the Wire: Improving Tor's Security with Trust-Aware Path Selection" by Aaron Johnson et al. - https://www.internetsociety.org/doc/avoding-man-wire-improving-tors-security-trust-aware-path-selection (more on proper path selection for Tor, possible attacks on Astoria). > Malware: "Dial One for Scam: A Large-Scale Analysis of Technical Support Scams" - наша статья, получившая Distinguished Paper Award! https://www.internetsociety.org/doc/dial-one-scam-large-scale-analysis-technical-support-scams "MaMaDroid: Detecting Android Malware by Building Markov Chains of Behavioral Models" by Enrico Mariconti et al. - https://www.internetsociety.org/doc/mamadroid-detecting-android-malware-building-markov-chains-behavioral-models "A Broad View of the Ecosystem of Socially Engineered Exploit Documents" by Stevens Le Blond et al. - https://www.internetsociety.org/doc/broad-view-ecosystem-socially-engineered-exploit-document s (можно проводить много интересных исследований на базе данных из VirusTotal). ... and much more interesting works on SGX, virtualization, and binary reassembly, etc. Plus, a DNS Privacy Workshop program - https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-programme
When we study IPSec, we know Mr. Diffie and Mr. Hellman invented a method in year 1976 that is the core of Internet Key Exchange (IKE) to create mutually shared secret. We also have to specify and configure DH Group Number in ISAKMP policy sets (crypto-map in Cisco IOS).A.M. Turing Award Logo. Captured on ACM Official Website.I am not going to dig in the details about the mathematics behind Diffie-Hellman method. I just want you to know Mr. Diffie and Mr. Hellman receive Turing Award 2015 together.Photo of Whitfield Diffie, captured on ACM Official Website.Photo of Martin E. Hellman, captured on ACM Website.A.M. Turing Award of Association for Computing Machinery (ACM) is the highest honorable award in computer science just like Nobel Prize for other fields of science.This was released on March 1, 2016.One more thing…In case you want to know more about Diffie-Hellman method, I found one video on YouTube is quite helpful for you to understand it more.Have fun!
I dagens extra långa radio bubb.la diskuterades USA:s senaste svek gentemot kurderna, rikspolischefens chockerande okunnighet om sina viktigaste uppgifter, ryska statsmediers selektiva nyhetsrapportering, den svenska liberalismens motbjudande krumbukter, rundgång i statsapparaten när myndigheter använder skattepengar för att lobba mot politiker, Schengenavtalet på randen till kollaps, opastöriserad mjölk i fokus för frihetskampen i USA, rekordfilibuster i Sydkorea, ny våg av nationalisering i Zimbabwe, inga osakliga löneskillnader kan påvisas mellan män och kvinnor i teknikbranschen, Goodyear uppfinner hjulet på nytt och Diffie-Hellman får Turing-priset. Dessutom vävde Martin in reseberättelser från libertarianska konferenser i USA och Mexiko och ett kommande specialavsnitt av en grannpodcast rekommenderades. http://radio.bubb.la/radio-bubb-la-53-2/
Fredrik Björeman från bland annat Kodsnack gästar podden! Security Fest, säkerhetskonferensen i Juni i Göteborg. presenteras av Jesper & Johan. Två olika webbläsarfiasko presenteras: opatchade WebKit kloner, samt Chromodo den helt trasiga versionen av Chrome. Övriga Nyheter: Java Deserialization är mycket värre än du tror enligt PayPal. Bedragare hackar polis/åklagare. CISCO har ett hål (vilket kom samma dag som podden spelades in, så vi har noll koll). IP kameror har massa problem, Shodan tar numera screenshots av dem, och creeps psykar småbarn via deras baby monitors. NorseCorps på ruinens kant, kommer de överleva efter omstrukturering? Diffie-Hellman är trasigt i en väldigt speciell konfiguration av OpenSSL, där man optimerar med ett hårdkodat primtal… som inte är ett primtal. Någon sorts rykte om fler säkerhetshål i Struts, och helt underbara regexps.
Intro / Outro Був’є – Стіна https://www.youtube.com/watch?v=4EWcKr5ei7Y CloudFlare is a free global CDN and DNS provider that can speed up and protect any site online https://www.cloudflare.com/dnssec/ Op-ed: (How) did they break Diffie-Hellman? http://goo.gl/nB7pXy Ransomware Now Gunning for Your Web Sites https://t.co/FQYuhUM813?ssr=true Linux Ransomware Debut Fails on Predictable Encryption Key http://goo.gl/OO4lD3 Let me tell you about Wireshark 2.0 https://goo.gl/AvMyNe Windows 3.1 Is Still Alive, And It Just Killed a French Airport https://goo.gl/mevwFB Oracle now keeps all EU data within EU borders to avoid Safe Harbour problems http://goo.gl/fjI3oi Halloween security breach https://goo.gl/V4ZgFN Updates to Chrome platform support http://goo.gl/MgIpTW Hack of 70 Million Prisoner Phone Calls Indicates Violations of Attorney-Client Privilege https://goo.gl/66lgfl The Secret Service Agent Who Collared Cybercrooks by Selling Them Fake IDs http://www.wired.com/2013/07/open-market/
AT&T Data Security Analysts discuss the AT&T Cybersecurity Conference, Cybersecurity Awareness Month, Android exploits, Diffie-Hellman , FinFisher, wifi attacks, and the Internet Weather Report. Originally recorded October 20, 2015.
In questa puntata parliamo della capacità dell'NSA di "forzare" l'algoritmo di Diffie-Hellman, che protegge le nostre connessioni SSL, SSH e VPN, e diamo un'infarinatura sulla steganografia.
Kodsnack 53 - Gör en Python 5 Kristoffer börjar berätta för Fredrik om sina öden och äventyr på svenska Pycon och tar med oss på en resa från datainsamling och bearbetning via kryptomysterier till Python 2 mot Python 3 och problemen med stora omstarter mellan versioner av mjukvara. Python 3 har stora problem med att vara något nytt och annorlunda som skiljer sig så mycket att den stora massan inte har anledning att byta till det. Samtidigt har utvecklarna av språket gått vidare så att ingen gör något alls med det språk folk faktiskt använder. Det finns en risk att man tappar det som gjorde ens skapelse värd att använda när man skriver om den för att bli modernare, mer generell eller vad man nu föresatt sig att göra. Avsnittet sponsras av Cenito. Länkar Pycon.se Fredrik Håård - huvudarrangören av Pycon.se Pycon internationellt Europython Mali Boko haram Bahnhofs datahall - tidigare civilförsvarsledningsplats - under Vita bergen i Stockholm Helena Bengtsson JOIN i databaser - kombinerar poster från flera tabeller Perl Fax OCR - optical character recognition Beautiful soup - pythonbibliotek för att få ut data ur webbsidor och annan mer eller mindre ostrukturerad data Kodsnack 5 - Kanelbullens dag nämnde också Beautiful soup Laurens Van Houtven Rackspace - sysslar med moln och hosting och anställer Laurens Kryptografi Engångsskiffer - teoretiskt perfekt kryptering med problem i verkligheten Diffie-Hellman key exchange Man-in-the-middle-attack Python 2 och Python 3 PyPI - Python package index och pip - ett program för att installera paket Pythons historia Unicode ASCII Indexera över en sträng, i Python 2 och i Python 3 Kenneth Reitz Requests - modul för HTTP i Python, som Kenneth skrivit Perl 6 - den ännu inte släppta versionen av Perl Generatorer - funktioner som genererar data Go - ett språk vi talat om förr Joel Spolsky om Netscapes omskrivning och att skriva om i allmänhet Winamp It really whips the llama's ass Winamp3 Det tycks fortfarande finnas lite liv i Winamp AOL - som var stora förr i tiden Dotcomkraschen Guido van Rossum Kärnutvecklare av Python 3 Python 2.7 blir den sista av Python 2 HTML 5 XHTML XSLT - språk för att omvandla XML-dokument till andra XML-dokument HTTP 2.0 SPDY - Googles nätverksprotokoll som är basen för HTTP 2.0 HTTP/2 considerations and tradeoffs - lång redogörelse med gott om länkar
This week on the show we'll be showing you how to set up RAID arrays in both FreeBSD and OpenBSD. There's also an interview with David Chisnall - of the FreeBSD core team - about the switch to Clang and a lot more. As usual, we'll be dropping the latest news and answering your emails, so sit back and enjoy some BSD Now - the place to B.. SD. This episode was brought to you by Headlines OpenBSD 5.5 released (http://www.openbsd.org/55.html) If you ordered (https://https.openbsd.org/cgi-bin/order) a CD set (https://twitter.com/blakkheim/status/461909893813784576) then you've probably had it for a little while already, but OpenBSD has formally announced the public release (http://undeadly.org/cgi?action=article&sid=20140501153339) of 5.5 This is one of the biggest releases to date, with a very long list of changes and improvements Some of the highlights include: time_t being 64 bit on all platforms, release sets and binary packages being signed with the new signify tool, a new autoinstall feature of the installer, SMP support on Alpha, a new AViiON port, lots of new hardware drivers including newer NICs, the new vxlan driver, relayd improvements, a new pf queue system for bandwidth shaping, dhcpd and dhclient fixes, OpenSMTPD 5.4.2 and all its new features, position-independent executables being default for i386, the RNG has been replaced with ChaCha20 as well as some other security improvements, FUSE support, tmpfs, softraid partitions larger than 2TB and a RAID 5 implementation, OpenSSH 6.6 with all its new features and fixes... and a lot more The full list of changes (http://www.openbsd.org/plus55.html) is HUGE, be sure to read through it all if you're interested in the details If you're doing an upgrade from 5.4 instead of a fresh install, pay careful attention to the upgrade guide (http://www.openbsd.org/faq/upgrade55.html) as there are some very specific steps for this version Also be sure to apply the errata patches (http://www.openbsd.org/errata55.html) on your new installations... especially those OpenSSL ones (some of which still aren't fixed (http://marc.info/?l=oss-security&m=139906348230995&w=2) in the other BSDs yet) On the topic of errata patches, the project is now going to also send them out (signed (http://undeadly.org/cgi?action=article&sid=20140502103355)) via the announce mailing list (http://lists.openbsd.org/cgi-bin/mj_wwwusr?user=&passw=&func=lists-long-full&extra=announce), a very welcome change Congrats to the whole team on this great release - 5.6 is going to be even more awesome with "Libre"SSL and lots of other stuff that's currently in development *** FreeBSD foundation funding highlights (http://freebsdfoundation.blogspot.com/2014/04/freebsd-foundation-spring-fundraising_28.html) The FreeBSD foundation posts a new update on how they're spending the money that everyone donates "As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of what we've done to help FreeBSD become the most innovative, reliable, and high-performance operation system" During this spring, they want to highlight the new UEFI boot support and newcons (http://freebsdfoundation.blogspot.com/2014/05/freebsd-foundation-newcons-project.html) There's a lot of details about what exactly UEFI is and why we need it going forward FreeBSD has also needed some updates to its console to support UTF8 and wide characters Hopefully this series will continue and we'll get to see what other work is being sponsored *** OpenSSH without OpenSSL (http://marc.info/?l=openbsd-cvs&m=139879453001957&w=2) The OpenSSH team has been hard at work, making it even better, and now OpenSSL is completely optional Since it won't have access to the primitives OpenSSL uses, there will be a trade-off of features vs. security This version will drop support for legacy SSH v1, and the only two cryptographic algorithms supported are an in-house implementation of AES in counter mode and the new combination (http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?rev=HEAD;content-type=text%2Fplain) of the Chacha20 stream cipher with Poly1305 for packet integrity Key exchange is limited to elliptic curve Diffie-Hellman and the newer Curve25519 KEXs No support for RSA, DSA or ECDSA public keys - only Ed25519 It also includes a new buffer API (http://marc.info/?l=openbsd-cvs&m=139883582313750&w=2) and a set of wrappers to make it compatible with the existing API Believe it or not, this was planned before all the heartbleed craziness Maybe someday soon we'll have a mini-openssh-portable in FreeBSD ports and NetBSD pkgsrc, would be really neat *** BSDMag's April 2014 issue is out (http://bsdmag.org/magazine/1861-free-pascal-on-bsd-april-bsd-issue) The free monthly BSD magazine has got a new issue available for download This time the articles include: pascal on BSD, an introduction to revision control systems and configuration management, deploying NetBSD on AWS EC2, more GIMP tutorials, an AsiaBSDCon 2014 report and a piece about how easily credit cards are stolen online Anyone can contribute to the magazine, just send the editors an email about what you want to write No Linux articles this time around, good *** Interview - David Chisnall - theraven@freebsd.org (mailto:theraven@freebsd.org) The LLVM/Clang switch, FreeBSD's core team, various topics Tutorial RAID in FreeBSD and OpenBSD (http://www.bsdnow.tv/tutorials/raid) News Roundup BSDTalk episode 240 (http://bsdtalk.blogspot.com/2014/04/bsdtalk240-about-time-with-george.html) Our buddy Will Backman has uploaded a new episode of BSDTalk, this time with our other buddy GNN as the guest - mainly to talk about NTP and keeping reliable time Topics include the specific details of crystals used in watches and computers to keep time, how temperature affects the quality, different sources of inaccuracy, some general NTP information, why you might want extremely precise time, different time sources (GPS, satellite, etc), differences in stratum levels, the problem of packet delay and estimating the round trip time, some of the recent NTP amplification attacks, the downsides to using UDP instead of TCP and... much more GNN also talks a little about the Precision Time Protocol (https://en.wikipedia.org/wiki/Precision_Time_Protocol) and how it's different than NTP Two people (http://www.bsdnow.tv/episodes/2014_01_29-journaled_news_updates) we've interviewed (http://www.bsdnow.tv/episodes/2014_03_05-bsd_now_vs_bsdtalk) talking to each other, awesome If you're interested in NTP, be sure to see our tutorial (http://www.bsdnow.tv/tutorials/ntpd) too *** m2k14 trip reports (http://undeadly.org/cgi?action=article&sid=20140502092427) We've got a few more reports from the recent OpenBSD hackathon in Morocco The first one is from Antoine Jacoutot (who is a key GNOME porter and gave us the screenshots for the OpenBSD desktop tutorial (http://www.bsdnow.tv/tutorials/the-desktop-obsd)) "Since I always fail at actually doing whatever I have planned for a hackathon, this time I decided to come to m2k14 unprepared about what I was going to do" He got lots of work done with ports and pushing GNOME-related patches back up to the main project, then worked on fixing ports' compatibility with LibreSSL Speaking of LibreSSL, there's an article (http://undeadly.org/cgi?action=article&sid=20140505062023) all would-be portable version writers should probably read and take into consideration Jasper Adriaanse also writes (http://undeadly.org/cgi?action=article&sid=20140501185019) about what he got done over there He cleaned up and fixed the puppet port to work better with OpenBSD *** Why you should use FreeBSD on your cloud VPS (https://www.atlantic.net/blog/2014/04/08/freebsd-ssd-cloud-vps-hosting-10-reasons/) Here we have a blog post from Atlantic, a VPS and hosting provider, about 10 reasons for using FreeBSD Starts off with a little bit of BSD history for those who are unfamiliar with it and only know Linux and Windows The 10 reasons are: community, stability, collaboration, ease of use, ports, security, ZFS, GEOM, sound and having lots of options The post goes into detail about each of them and why FreeBSD makes a great choice for a VPS OS *** PCBSD weekly digest (http://blog.pcbsd.org/2014/05/weekly-feature-digest-27-software-system-redesign/) Big changes coming in the way PCBSD manages software The PBI system, AppCafe and related tools are all going to use pkgng now The AppCafe will no longer be limited to PBIs, so much more software will be easily available from the ports tree New rating system coming soon and much more *** Feedback/Questions Martin writes in (http://slexy.org/view/s21bk2oPuQ) John writes in (http://slexy.org/view/s2n9fx1Rpw) Alex writes in (http://slexy.org/view/s2rBBKLA4u) Goetz writes in (http://slexy.org/view/s20JY6ZI71) Jarrad writes in (http://slexy.org/view/s20YV5Ohpa) ***
On this week's episode, we'll be talking with Ted Unangst of the OpenBSD team about their new signing infrastructure. After that, we've got a tutorial on how to run your own NTP server. News, your feedback and even... the winner of our tutorial contest will be announced! So stay tuned to BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD foundation's 2013 fundraising results (http://freebsdfoundation.blogspot.com/2014/01/freebsd-foundation-announces-2013.html) The FreeBSD foundation finally counted all the money they made in 2013 $768,562 from 1659 donors Nice little blog post from the team with a giant beastie picture "We have already started our 2014 fundraising efforts. As of the end of January we are just under $40,000. Our goal is to raise $1,000,000. We are currently finalizing our 2014 budget. We plan to publish both our 2013 financial report and our 2014 budget soon." A special thanks to all the BSD Now listeners that contributed, the foundation was really glad that we sent some people their way (and they mentioned us on Facebook) *** OpenSSH 6.5 released (https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032152.html) We mentioned the CFT last week, and it's finally here (https://news.ycombinator.com/item?id=7154925)! New key exchange using elliptic-curve Diffie Hellman in Daniel Bernstein's Curve25519 (now the default when both clients support it) Ed25519 public keys are now available for host keys and user keys, considered more secure than DSA and ECDSA Funny side effect: if you ONLY enable ed25519 host keys, all the compromised Linux boxes can't even attempt to login (http://slexy.org/view/s2rI13v8F4) lol~ New bcrypt private key type, 500,000,000 times harder to brute force Chacha20-poly1305 transport cipher that builds an encrypted and authenticated stream in one Portable version already in (https://svnweb.freebsd.org/base?view=revision&revision=261320) FreeBSD -CURRENT, and ports (https://svnweb.freebsd.org/ports?view=revision&sortby=date&revision=342618) Lots more bugfixes and features, see the full release note or our interview (http://www.bsdnow.tv/episodes/2013_12_18-cryptocrystalline) with Damien Work has already started on 6.6, which can be used without OpenSSL (https://twitter.com/msfriedl/status/427902493176377344)! *** Crazed Ferrets in a Berkeley Shower (http://blather.michaelwlucas.com/archives/1942) In 2000, MWL (http://www.bsdnow.tv/episodes/2013_11_06-year_of_the_bsd_desktop) wrote an essay for linux.com about why he uses the BSD license: "It's actually stood up fairly well to the test of time, but it's fourteen years old now." This is basically an updated version about why he uses the BSD license, in response to recent comments from Richard Stallman (http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html) Very nice post that gives some history about Berkeley, the basics of the BSD-style licenses and their contrast to the GNU GPL Check out the full post if you're one of those people that gets into license arguments The takeaway is "BSD is about making the world a better place. For everyone." *** OpenBSD on BeagleBone Black (http://www.tedunangst.com/flak/post/OpenBSD-on-BeagleBone-Black) Beaglebone Blacks are cheap little ARM devices similar to a Raspberry Pi A blog post about installing OpenBSD on a BBB from.. our guest for today! He describes it as "everything I wish I knew before installing the newly renamed armv7 port on a BeagleBone Black" It goes through the whole process, details different storage options and some workarounds Could be a really fun weekend project if you're interested in small or embedded devices *** Interview - Ted Unangst - tedu@openbsd.org (mailto:tedu@openbsd.org) / @tedunangst (https://twitter.com/tedunangst) OpenBSD's signify (http://www.tedunangst.com/flak/post/signify) infrastructure, ZFS on OpenBSD Tutorial Running an NTP server (http://www.bsdnow.tv/tutorials/ntpd) News Roundup Getting started with FreeBSD (http://smyck.net/2014/02/01/getting-started-with-freebsd/) A new video and blog series about starting out with FreeBSD The author has been a fan since the 90s and has installed it on every server he's worked with He mentioned some of the advantages of BSD over Linux and how to approach explaining them to new users The first video is the installation, then he goes on to packages and other topics - 4 videos so far *** More OpenBSD hackathon reports (http://undeadly.org/cgi?action=article&sid=20140204080515) As a followup to last week, this time Kenneth Westerback writes about his NZ hackathon experience He arrived with two goals: disklabel fixes for drives with 4k sectors and some dhclient work This summary goes into detail about all the stuff he got done there *** X11 in a jail (https://svnweb.freebsd.org/base?view=revision&revision=261266) We've gotten at least one feedback email about running X in a jail Well.. with this commit, looks like now you can! A new tunable option will let jails access /dev/kmem and similar device nodes Along with a change to DRM, this allows full X11 in a jail Be sure to check out our jail tutorial and jailed VNC tutorial (http://www.bsdnow.tv/tutorials) for ideas *** PCBSD weekly digest (http://blog.pcbsd.org/2014/01/whoami-im-pc-bsd-10-0-weekly-feature-digest-15/) 10.0 "Joule Edition" finally released (http://blog.pcbsd.org/2014/01/pc-bsd-10-0-release-is-now-available/)! AMD graphics are now officially supported GNOME3, MATE and Cinnamon desktops are available Grub updates and fixes PCBSD also got a mention in eweek (http://www.eweek.com/enterprise-apps/slideshows/freebsd-open-source-os-comes-to-the-pc-bsd-desktop.html) *** Feedback/Questions Justin writes in (http://slexy.org/view/s21VnbKZsH) Daniel writes in (http://slexy.org/view/s2nD7RF6bo) Martin writes in (http://slexy.org/view/s2jwRrj7UV) Alex writes in (http://slexy.org/view/s201koMD2c) - unofficial FreeBSD RPI Images (http://people.freebsd.org/~gjb/RPI/) James writes in (http://slexy.org/view/s2AntZmtRU) John writes in (http://slexy.org/view/s20bGjMsIQ) ***
We follow up last week's poudriere tutorial with a segment about using pkgng, we talk with the developers of OpenSMTPD about running a mail server OpenBSD-style, answer YOUR questions and, of course, discuss all the latest news. All that and more on BSD Now! The place to B... SD. Headlines pfSense 2.1-RELEASE is out (http://blog.pfsense.org/?p=712) Now based on FreeBSD 8.3 Lots of IPv6 features added Security updates, bug fixes, driver updates PBI package support Way too many updates to list, see the full list (https://doc.pfsense.org/index.php/2.1_New_Features_and_Changes) *** New kernel based iSCSI stack comes to FreeBSD (https://lists.freebsd.org/pipermail/freebsd-current/2013-September/044237.html) Brief explanation of iSCSI This work replaces the older userland iscsi target daemon and improves the in-kernel iscsi initiator Target layer consists of: ctld(8), a userspace daemon responsible for handling configuration, listening for incoming connections, etc, then handing off connections to the kernel after the iSCSI Login phase iSCSI frontend to CAM Target Layer, which handles Full Feature phase. The work is being sponsored by FreeBSD Foundation Commit here (http://freshbsd.org/commit/freebsd/r255570) *** MTier creates openup utility for OpenBSD (http://www.mtier.org/index.php/solutions/apps/openup/) MTier provides a number of things for the OpenBSD community For example, regularly updated (for security) stable packages from their custom repo openup is a utility to easily check for security updates in both base and packages It uses the regular pkg tools, nothing custom-made Can be run from cron, but only emails the admin instead of automatically updating *** OpenSSH in FreeBSD -CURRENT supports DNSSEC (https://lists.freebsd.org/pipermail/freebsd-security/2013-September/007180.html) OpenSSH in base is now compiled with DNSSEC support In this case the default setting for ‘VerifyHostKeyDNS' is yes OpenSSH will silently trust DNSSEC-signed SSHFP records It is the secteam's opinion that this is better than teaching users to blindly hit “yes” each time they encounter a new key *** Interview - Gilles Chehade & Eric Faurot - gilles@poolp.org (mailto:gilles@poolp.org) / @poolpOrg (https://twitter.com/poolpOrg) & eric@openbsd.org (mailto:eric@openbsd.org) / @opensmtpd (https://twitter.com/opensmtpd) OpenSMTPD Tutorial Binary packages with pkgng (http://www.bsdnow.tv/tutorials/pkgng) News Roundup New progress with Newcons (http://raybsd.blogspot.com/2013/08/newcons-beginning.html) Newcons is a replacement console driver for FreeBSD Supports unicode, better graphics modes and bigger fonts Progress is being made, but it's not finished yet *** relayd gets PFS support (http://freshbsd.org/commit/openbsd/7e7bd0a7f61ea0005b5c2f763364ff8dfce03fe2) relayd is a load balancer for OpenBSD which does protocol layers 3, 4, and 7 Currently being ported to FreeBSD. There is a WIP port (https://www.freshports.org/net/relayd/) Works by negotiating ECDHE (Elliptic curve Diffie-Hellman) between the remote site and relayd to enable TLS/SSL Perfect Forward Secrecy, even when the client does not support it *** OpenZFS Launches (http://open-zfs.org/wiki/Main_Page) Slides from LinuxCon (http://www.slideshare.net/MatthewAhrens/open-zfs-linuxcon) Will feature ‘Office Hours' (Ask an Expert) Goal is to reduce the differences between various open source implementations of ZFS, both user facing and pure lines of code *** FreeBSD 10-CURRENT becomes 10.0-ALPHA (http://freshbsd.org/commit/freebsd/r255489) Glen Barber tagged the -CURRENT branch as 10.0-ALPHA In preparation for 10.0-RELEASE, ALPHA2 as of 9/16 Everyone was rushing to get their big commits in before 10-STABLE, which will be branched soon 10 is gonna be HUGE (https://wiki.freebsd.org/WhatsNew/FreeBSD10) *** September issue of BSD Mag (http://bsdmag.org/magazine/1848-day-to-day-bsd-administration) BSD Mag is a monthly online magazine about the BSDs This month's issue has some content written by Kris Topics include MidnightBSD live cds, server maintenance, turning a Mac Mini into a wireless access point with OpenBSD, server monitoring, FreeBSD programming, PEFS encryption and a brief introduction to ZFS *** The FreeBSD IRC channel is official For many years, the FreeBSD freenode channel has been “unofficial” with a double-hash prefix Finally it has freenode's blessing and looks like a normal channel! The old one will forward to the new one, so your IRC clients don't need updating *** OpenSSH 6.3 released (https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-September/031638.html) After a big delay, Damien Miller announced the release of 6.3 Mostly a bugfix release, with a few new features Of note, SFTP now supports resuming failed downloads via -a *** Feedback/Questions [James writes in](http://slexy.org/view/s2wBbbSWGz] [Elias writes in](http://slexy.org/view/s2LMDF3PYx] [Gabor writes in](http://slexy.org/view/s2aCodo65X] Possibly the coolest feedback we've gotten thus far: Baptiste Daroussin, leader of the FreeBSD ports management team and author of poudriere and pkgng, has put up the BSD Now poudriere tutorial on the official documentation! ***
Dopo aver scartato l'idea di Luca di sostituire Alice e Bob con Amanda e Bruno, Filippo ci spiega uno degli argomenti della sua tesina di maturità: l'algoritmo di scambio di chiavi Diffie-Hellman.
We describe the Diffie-Hellman key-exchange protocol and the Pohlig-Hellman cipher. We discuss discrete logarithms and the cryptanalysis of these two systems. We also describe the Mental Poker protocol. About the speaker: Before coming to Purdue, Professor Wagstaff taught at the Universities of Rochester, Illinois, and Georgia. He spent a year at the Institute for Advanced Study in Princeton. His research interests are in the areas of cryptography, parallel computation, and analysis of algorithms, especially number theoretic algorithms. He and J. W. Smith of the University of Georgia have built a special processor with parallel capability for factoring large integers.
We describe the Diffie-Hellman key-exchange protocol and the Pohlig-Hellman cipher. We discuss discrete logarithms and the cryptanalysis of these two systems. We also describe the Mental Poker protocol.
© 2020-2025 Ivy Podcast Discovery LLC
