#brute force the algorithm | Explore Tumblr Posts and Blogs

evilminji · 27 days

Text

Been Watching Weird Fruit Explorer(?)... and I just...

W-Who let Bored Danny have BooTube?

Sorry, YOU-Tube. He has TWO Apps now. BooTube is bigger. Way more random, yet... somehow more niche? Meh. It's what happens when you get billions of billions of people who all have their own Obsessions to rant over, on a site.

Ember's channel is pretty lit, tho, ngl.

He stopped using YOU-Tube almost overnight. Too many ads, weird algorithmic pushiness. No thanks. It was too small and too "trying to take my money". You know?

Buuuuut? See.... TUCKER is the Tech guy.

Coding and that sort of stuff. HE does hands on work. You want a toaster? He can MAKE you a toaster! With LAZERS! Runs off The Goo! But a program? Eeeeeeeh? Hit it with hammer maybe? Monkey make fire? Hit with stick? Blergh.

Yeah, he can SORTA push through.

But he suuuucks.

And like... he had a headache, okay? His project had just, quiet literally, exploded in his face. So when he looked at his phone? All the apps were blobs. He clicked the one that LOOKED kinda right. Shoved his arm in his phone and brute forced a channel set up.

He figured he could ramble about Space!

It's not like he cared is anyone LISTENS or not! It's a "for him" thing, you know? Like a diary. But more... putting on a ☆~show~☆?

So he rambles from the floor of his Lair's Lab, crashs and wails in the distance, green sky occasionally visible as he lazily floats by windows. Dropping... juuuust past human knowledge understanding of Space. Talking like he's STUDYING somewhere. Referencing PAPERS no human will ever be able to find.

But a few they WILL.

Some of which, are currently? Only half written.

But then? Oh YEAH... he should eat! You know... Sam keeps bringing him fruits and veggies and stuff from her internship at that Botanical Lair. Stuff never seen before of Earth. Or hasn't been seen in centuries.

Again, like, a FEW that? Randomly? Have???

He picks up something sharply purple, bright orange insides. Crisp crunch. He makes a face. And starts to ramble about it, distracted from Space. "Weirdly mushroom-y" he notes. "Kinda bubblegum sweet? But like... CHEAP bubblegum. Like it hits you all at once and is kinda chemically. But it disappears real fast? Huh. Spicy too..."

It's the first video on the Playlist. One of hundreds. Two of the green Lanterns RECONIZE that fruit ad HIGHLY toxic to humans, can't recognize what planet they're seeing. Or how this alien teen got himself on YouTube.

He seems... unaware of how incredibly famous he's become.

But his strange techno Pharoah friend has not. HE is both perfectly aware and apparently amused. Has taken to feeding him rare and hazardous flora and fauna, to see if it tastes good.

....there have been an alarming number of plants from dead planets.

And the comments the kid makes? Alarming as hell.

Sam's just pleased everybody's getting their greens. Danny's glad him n tuck get to hang and do "try weird foods and fuck around, bro time". They've made lazers! Talked about stuff! Debated why Martian Manhunter is THE superior Justice League member.

Danny understands. Wonder Woman is a BAMF. But he's biased, Tucker. He doesn't CARE if she has a sword and flowy, impressive locks! Shape-shifting telepath! From MARS!!! *imaginary mic drop*

And Tucker? Is conquering the YouTube scene with this charming, weird, relatable young alien. Who rambles about Space, debates nerd stuff, eats weird plants and describes them, and makes sci-fi technology! Theme? WHAT THEME? Phantom is a weird channel, man. You never know what you'll find!

And no one can get rid of it.

Believe them, governments have TRIED. Censorship? Not possible. Not without removing the whole SITE.

#dpxdc #dp x dc #dc x dp #dcxdp #minji's writing #bootube to youtube au #internet famous au

2K notes · View notes

blubberquark · 10 months

Text

Why Not Write Cryptography

I learned Python in high school in 2003. This was unusual at the time. We were part of a pilot project, testing new teaching materials. The official syllabus still expected us to use PASCAL. In order to satisfy the requirements, we had to learn PASCAL too, after Python. I don't know if PASCAL is still standard.

Some of the early Python programming lessons focused on cryptography. We didn't really learn anything about cryptography itself then, it was all just toy problems to demonstrate basic programming concepts like loops and recursion. Beginners can easily implement some old, outdated ciphers like Caesar, Vigenère, arbitrary 26-letter substitutions, transpositions, and so on.

The Vigenère cipher will be important. It goes like this: First, in order to work with letters, we assign numbers from 0 to 25 to the 26 letters of the alphabet, so A is 0, B is 1, C is 2 and so on. In the programs we wrote, we had to strip out all punctuation and spaces, write everything in uppercase and use the standard transliteration rules for Ä, Ö, Ü, and ß. That's just the encoding part. Now comes the encryption part. For every letter in the plain text, we add the next letter from the key, modulo 26, round robin style. The key is repeated after we get tot he end. Encrypting "HELLOWORLD" with the key "ABC" yields ["H"+"A", "E"+"B", "L"+"C", "L"+"A", "O"+"B", "W"+"C", "O"+"A", "R"+"B", "L"+"C", "D"+"A"], or "HFNLPYOLND". If this short example didn't click for you, you can look it up on Wikipedia and blame me for explaining it badly.

Then our teacher left in the middle of the school year, and a different one took over. He was unfamiliar with encryption algorithms. He took us through some of the exercises about breaking the Caesar cipher with statistics. Then he proclaimed, based on some back-of-the-envelope calculations, that a Vigenère cipher with a long enough key, with the length unknown to the attacker, is "basically uncrackable". You can't brute-force a 20-letter key, and there are no significant statistical patterns.

I told him this wasn't true. If you re-use a Vigenère key, it's like re-using a one time pad key. At the time I just had read the first chapters of Bruce Schneier's "Applied Cryptography", and some pop history books about cold war spy stuff. I knew about the problem with re-using a one-time pad. A one time pad is the same as if your Vigenère key is as long as the message, so there is no way to make any inferences from one letter of the encrypted message to another letter of the plain text. This is mathematically proven to be completely uncrackable, as long as you use the key only one time, hence the name. Re-use of one-time pads actually happened during the cold war. Spy agencies communicated through number stations and one-time pads, but at some point, the Soviets either killed some of their cryptographers in a purge, or they messed up their book-keeping, and they re-used some of their keys. The Americans could decrypt the messages.

Here is how: If you have message $A$ and message $B$, and you re-use the key $K$, then an attacker can take the encrypted messages $A+K$ and $B+K$, and subtract them. That creates $(A+K) - (B+K) = A - B + K - K = A - B$. If you re-use a one-time pad, the attacker can just filter the key out and calculate the difference between two plaintexts.

My teacher didn't know that. He had done a quick back-of-the-envelope calculation about the time it would take to brute-force a 20 letter key, and the likelihood of accidentally arriving at something that would resemble the distribution of letters in the German language. In his mind, a 20 letter key or longer was impossible to crack. At the time, I wouldn't have known how to calculate that probability.

When I challenged his assertion that it would be "uncrackable", he created two messages that were written in German, and pasted them into the program we had been using in class, with a randomly generated key of undisclosed length. He gave me the encrypted output.

Instead of brute-forcing keys, I decided to apply what I knew about re-using one time pads. I wrote a program that takes some of the most common German words, and added them to sections of $(A-B)$. If a word was equal to a section of $B$, then this would generate a section of $A$. Then I used a large spellchecking dictionary to see if the section of $A$ generated by guessing a section of $B$ contained any valid German words. If yes, it would print the guessed word in $B$, the section of $A$, and the corresponding section of the key. There was only a little bit of key material that was common to multiple results, but that was enough to establish how long they key was. From there, I modified my program so that I could interactively try to guess words and it would decrypt the rest of the text based on my guess. The messages were two articles from the local newspaper.

When I showed the decrypted messages to my teacher the next week, got annoyed, and accused me of cheating. Had I installed a keylogger on his machine? Had I rigged his encryption program to leak key material? Had I exploited the old Python random number generator that isn't really random enough for cryptography (but good enough for games and simulations)?

Then I explained my approach. My teacher insisted that this solution didn't count, because it relied on guessing words. It would never have worked on random numeric data. I was just lucky that the messages were written in a language I speak. I could have cheated by using a search engine to find the newspaper articles on the web.

Now the lesson you should take away from this is not that I am smart and teachers are sore losers.

Lesson one: Everybody can build an encryption scheme or security system that he himself can't defeat. That doesn't mean others can't defeat it. You can also create an secret alphabet to protect your teenage diary from your kid sister. It's not practical to use that as an encryption scheme for banking. Something that works for your diary will in all likelihood be inappropriate for online banking, never mind state secrets. You never know if a teenage diary won't be stolen by a determined thief who thinks it holds the secret to a Bitcoin wallet passphrase, or if someone is re-using his banking password in your online game.

Lesson two: When you build a security system, you often accidentally design around an "intended attack". If you build a lock to be especially pick-proof, a burglar can still kick in the door, or break a window. Or maybe a new variation of the old "slide a piece of paper under the door and push the key through" trick works. Non-security experts are especially susceptible to this. Experts in one domain are often blind to attacks/exploits that make use of a different domain. It's like the physicist who saw a magic show and thought it must be powerful magnets at work, when it was actually invisible ropes.

Lesson three: Sometimes a real world problem is a great toy problem, but the easy and didactic toy solution is a really bad real world solution. Encryption was a fun way to teach programming, not a good way to teach encryption. There are many problems like that, like 3D rendering, Chess AI, and neural networks, where the real-world solution is not just more sophisticated than the toy solution, but a completely different architecture with completely different data structures. My own interactive codebreaking program did not work like modern approaches works either.

Lesson four: Don't roll your own cryptography. Don't even implement a known encryption algorithm. Use a cryptography library. Chances are you are not Bruce Schneier or Dan J Bernstein. It's harder than you thought. Unless you are doing a toy programming project to teach programming, it's not a good idea. If you don't take this advice to heart, a teenager with something to prove, somebody much less knowledgeable but with more time on his hands, might cause you trouble.

#programming #cryptography #learn programming #teaching programming

346 notes · View notes

ms-demeanor · 5 months

Note

Nahhhh you lost me at the copyright bullshit. A machine created to brute force copy and learn from any and all art around it that then imitates the work of others, an algorithm that puts no effort of its own into work, is not remotely comparable to a human person who learns from others' art and puts work and effort into it. One is an algorithm made by highly paid dudebros to copy things en masse, another is the earnest work of one person.

I mean. You're fundamentally misunderstanding both the technology and my argument.

You're actually so wrong you're not even wrong. Let's break it down:

A machine created to brute force copy and (what does "brute force copy" mean? "Brute Force" has a specific meaning in discussions of tech and this isn't it) learn from any and all art around it that then imitates the work of others (there are limited models that are trained to imitate the work of specific artists and there are people generating prompts requesting things in the style of certain artists, but large models are absolutely not trained to imitate anything other than whatever most closely matches the prompt; I do think that models trained on a single artist are unethical and are a much better case of violating the principles of fair use however they are significantly transformative so even there the argument kind of falls apart), an algorithm that puts no effort of its own into work (of course this is not a fair argument to be having really because you're an asker and you can't argue or respond but buddy you have to define your terms. 'Effort' is an extremely malleable concept and art that takes effort is not significantly more art-y or valid than art that takes little or no effort like this is an extremely common argument in discussions of modern art - is Andy Warhol art, is Duchamps' readymades series art, art is a LOT more about context than effort and I'm not sure you're aware of the processing power used to generate AI art but there is "effort" of a sort there but also you are anthropomorphizing the model, the algorithm isn't generating "its own work"), is not remotely comparable to a human person who learns from others' art and puts work and effort into it. One is an algorithm (i mean it's slightly more complicated than that, we're discussing a wide variety of models here) made by highly paid dudebros (this completely ignores the open source work, the volunteer work, the work of anybody who is not a 'dudebro,' which is the most typically tumblr way of dismissing anything in tech as the creation of someone white, male, and wealthy which SUCH a shitty set of assumptions) to copy things en masse, another is the earnest work of one person.

Okay so the reasonable things I've pulled out of that to discuss are:

"A machine created to learn from any and all art around it is not remotely comparable to a human person who learns from others' art and puts work and effort into it. One is an algorithm made to copy things en masse, another is the earnest work of one person."

And in terms of who fair use applies to, no. You're wrong. For the purposes of copyright and fair use, a machine learning model and a person are identical. You can't exclude one without excluding the other. There isn't even a good way to meaningfully separate them if you consider artists who use AI in their process while not actually generating AI art.

I feel like I don't really have to make much of an argument here because the EFF has done it for me. The sections of that commentary from question 8 own are detailed explanations of why generative models should reasonably be recognized as protected by fair use when trained on data that is publicly available.

But also: your definition of "copying" is bad. You're wrong about what a copy is, or you're wrong about what generative image models do. I suspect that the latter is much closer to the truth, so I'd recommend reading up on generative image models some more - that EFF commentary has plenty of articles that would probably be helpful for you.

126 notes · View notes

friendlymathematician · 4 months

Note

Hello! Sorry if this seems off topic, but literally how do I get better at math and find it enjoyable?

practise, and finding something you enjoy practising.

more concretely, most maths education before university level is shit. you learn to apply algorithms in strictly controlled contexts, and very little to nothing about why things work the way they do, which is what's actually fun. exactly what you might find fun varies, but one thing where you get to think a lot about the "why" is discrete mathematics.

disclaimer: i don't necessarily come up with these from the perspective of someone who is bad at maths. also, regrettably, there's very little popsci maths written/created by women. depending on what you want to do, and what level you're currently at, a few things that might be fun to look at are:

khanacademy (basic school-style practise, with good explanations that tend to be a bit more intuitive than most teachers)

the book "how to think like a mathematician" (introduction to thinking mathematically and discrete maths, intended as a preparation for university level maths)

the book "proofs and refutations" (philosophy, a socratic dialogue discussing how to prove statements in mathematics and what it means to prove something)

the article series "how euler did it" (a bunch of 3-5 page explanations, heavy on the intuition, of some of the most fun proofs of leonard euler)

quanta magazine (excellent science journalism which includes mathematics, where they try to explain what mathematicians actually do)

project euler (if you like/want to learn basic programming, the first few can be brute forced but then you have to start trying to learn combinatorics/number theory)

popsci maths books: the joy of x, fermat's last theorem, the code book, e: the story of a number

57 notes · View notes

patricia-taxxon · 7 months

Text

I enjoy the infinite space element of prime mover, like i never feel like an otherwise good solution is ruined by space limitations but its not free either. the nested sub-boards still only have four ways in and out, u have to consider how your new chip interfaces with the program. my extravagant sorting algorithm with heaps of spaghetti edge case detection that goes 3 layers deep doesn't feel like a "brute force" solution, because every time I introduced more space it was a considered process.

#cilantromixture #prime mover

66 notes · View notes

neon-prison · 1 year

Note

🩺🚓 annnnd 🚖 (I have no capacity ro read fics atm but I want to knoooow!) - for your new meme :3

tysm for the asks!! and so sorry I've been late with these (because I chose to draw them like a CLOWN). @kohnnor @togepies

From the Get-A-Long Meme!

For length purposes- info under the cut!

Vee and River:

River arrested Vee back in time with a minor charge, but on the way to the station, they got embroiled in a series of wacky hijinks, starting with a car chase and ending with burritos under the highway. River and Vee developed a working relationship that eventually evolved into a pretty cheesy friendship, with River being a bit of a lighthearted bully/tease. But don't be fooled by the big brother routine- River has it BAD for Vee. However, Vee comes from Heywood Streets, and while she is no longer a Valentino, a relationship with a cop would be disastrous on all fronts. Padre and his cadre of contacts are...tolerant of her friendship, but only so far as it doesn't cross the line. Anything more would not only ruin Vee's clout/trust from the Heywood community, but any perceived 'threat' would also put a giant target on River and, by extension, his family. She'd essentially end up trading her life for a lover. Unfortunately, River, while a sweetheart, struggles to see the bigger picture, so it's up to Vee to maintain that boundary.

But even beyond that, Vee isn't sure she's suited for the family life that River clearly wants. She's ride or die, of course, but freedom is important to her. Maybe in another lifetime, they could have been something more, but Night City's boundaries etch further than simple geography.

Vee and Delamain:

My main ship! "This isn't a cab this is a clown car"

Vee met Delamain during the game's events and got his attention/tentative admiration for choosing to reset his core- an act he considered to be anecdotally counter to most human's deep admiration for independence and free will. Their subsequent conversations about human nature and close contact quenched what used to be pretty starved heuristic/social algorithms. Eventually, their tentative client/business relationship evolved into friendship, and Delamain became bold enough to start freeing himself of previous strictures and protocols to engage with Vee on a more informal basis.

Personality-wise, they get along extremely well. Vee is always happy to have a new friend, and her ride-or-die (haha) nature means that she'll always have Delamain's back. On Delamain's end, it's a novel but thrilling experience to interact with someone who doesn't consider him an automaton. He finds Vee's ambition and intensity extremely admirable and a mirror to his own struggle for survival in Night City.

Vee, Mitch and Saul:

Despite her stationary life, Vee has all the trappings of a nomad; fiercely independent, loyal, flexible, and, most importantly, open-minded to possibilities beyond the horizon. From the moment she made friends with the Aldecaldos, they saw some kindred flame, though perhaps they realized too late that her soul belonged to the city.

Saul:

While Panam grew up in an isolated environment, Vee, having survived in Night City, sees how deeply and inseparably all the social pieces intertwine. Unlike Panam, she understands that survival isn't just a test of brute force and that you have to be able to bend and sway to the incoming winds to get ahead. Surprisingly enough, she and Saul understand one another's motivations very well, and while Vee can be impulsive, she's also got a level of foresight that he appreciates. Like Panam, Saul struggles with the idea of leaving Vee behind, and in an alternate timeline, they would have probably gotten together.

Mitch:

Mitch considers Vee to be Panam's long-lost sister and appreciates that Vee can be the level-headed anchor to Panam's fiery, impulsive nature. Over the course of their acquaintance, Vee demonstrated all of the qualities Mitch likes in a person: loyalty, dependability, flexibility, etc. Like Saul and Panam, Mitch really really wishes Vee would ditch Night City to join them, though he knows his entreaties are pointless.

Vee and Vik:

Vee has known Vik since she was a teen, with Jackie having introduced them. At first, she was a bit of a pest, popping in, constantly curious, and disrupting his work till he'd had enough. However, she ran a tough gig to get him some much-needed supplies for almost no pay, and a few years later, he repaid the favor by giving Vee her prized gorilla arms: "Special gold order, just for you." Since then, they've maintained an exasperated mentor/annoying protege relationship that Vee relies on till today. For Vik's part, he's more than happy to have a skilled merc on his side, and everyone knows his clinic is under the VVasp's protection. And if he calls Vee to ask her advice on dating/fashion advice well...that's doctor/patient confidentiality.

#cyberpunk 2077 #river ward #saul bright #mitch anderson #delamain #viktor vektor #oc:vee #neon_draws #ask meme #not my clown ass going through 10000 diff styles lmao

238 notes · View notes

foundationsofdecay · 3 months

Text

"These days I'm a circuit board", Vessel broken down to his bare essentials, like metadata, the ghosts of what he used to be that's long-since deleted, ported into a new image, a new program, half-algorithm to suit his other half, the deity that's shaped him into something new, something so much more yet so much less. when he starts to second guess himself his voice starts to hiss static and sizzle and crack - "did you not say we were made for each other?"

And when he becomes too stressed and overclocked he heats up to the point of shutting down entirely, spitting out warnings and errors and panicked readouts before he's forced to turn off and reset - "you have become the voice in my head / only recourse we're left after death".

Programmed by brute force into something that will follow Sleep's demands, but he's built entirely out of scrap parts, running on spaghetti code that will break apart at the slightest change and provocation and deletion, prompting further ugly patches, until the only thing that can save him is a complete rewrite, a full refactoring, something to untangle and remove the unneeded clutter and garbage code from his base, just like the rain that will cleanse him, a complete saturation.

A rebirth into something new.

#eepy toking #you make me wish i could disappear!

27 notes · View notes

blake447 · 5 months

Text

Alright! On to the next step in my quest for procedural dungeon generation. In my previous posts, I went over generating and seperating the rooms, a little bit of triangle math, and delaunay triangulation, the result of which you see above. Now that we have some set of nodes triangulated, we need to convert them into a proper graph. Essentially what I do is just iterate over everything (working first, optimize later) to brute force all the points neighbors. And thats the graph you see above, where the green one underlying it has edges generated by triangles, this one has edges generated by neighborhood.

Next we pair this graph with a graph of connectivity of all rooms. Using the delauney triangulation to determine points A and B, we apply some kind of path finding algorithm to connect those points with rooms based on their connectivity.

I'm implementing A* because of course I am, and here we have the first initial test case where I just try to find a path between rooms 0, and 1, which have no meaningful interpretation but once again, are for testing purposes. It appears to be working! We aren't necessarily looking for the most optimal route so that simplifies things a little bit.

Update We are in fact looking for the optimal round because holy hell did this heuristic not work well lol. The resulting web is way to stringent, and nearly includes every pathway anyway, leading to an unsatisfying dungeon. I kind of... didn't implement A* so that may be it, but at least we have snazzy visuals for when we do implement it

#game dev #progblr #mathblr #codeblr #programming #gamedev #mathematics #math #unity3D #graph theory #pathfinding

22 notes · View notes

kaiserouo · 1 month

Text

Do you know what string art is?

Yeah that thing. Kinda. Maybe.

For anyone curious, the setup is:

600 nails around the perimeter. (image size 540x360)

3 ropes (RGB) going from one nail to the next. Each rope does this 2442 times.

The algorithm (at least the implementation I took from Github) is to literally brute force every possible pin and use the L2 distance from the resulting image to the last step to determine the best next pin every step. Greedily does this until no improvement is possible.

Easily enough for computers and quite effective even if it's a greedy heuristic approach. Not really parallelize-able other than the 3 ropes so this took 10 minutes to generate.

#kinda magical #i kinda have the direction about the algorithm after seeing someone do this physically and wanted to code my own #but after that experience with the blender addon i searched on github first #yoink #their distance function is better than mine anyway lol my original design / thought is so flawed #apex legends #apex bloodhound #bloodhound #bloodhound apex #welp not my art definitely but i can say this is a #render

13 notes · View notes

argumate · 3 months

Text

I know nothing about this but here's an argument that neural network architecture doesn't matter:

assume you're applying a black box machine learning method to a large training set in order to create a function that models it, and importantly the function is smaller than the training set so it must be approximating it in ways that will generalise well to data outside the training set, assuming that training set is representative.

(it's not actually necessary for the function to be smaller than its training set but it's convenient given that the ultimate training set is the entire universe and it also guarantees that it can't just be literally memorising the input you give it and returning garbage for anything it hasn't seen before).

some possible training sets for your function:

a question -> the answer

parts of images -> the rest of the image

texts in one language -> the same text in a different language

a frame from a video -> the following frame in the video

the weather at time N -> the weather at time N+1

and so on, just keep pouring data into this black box and get back a function that approximates that data as best it can.

what is the architecture of the function? who cares! you only care about minimising the error, reducing the delta between its answers and the training set, better architectures might achieve lower error rates and asymptotically approach the minimum possible error for a given function size, but all the clever stuff is in the data and the more clever the architecture gets the less it impacts the result.

in the extreme case imagine you had a hyper turing oracle where you give it a fully connected neural network of a given size and it adjusts the weights to achieve the minimum possible error on the training set in constant time: such a device could not exist in this universe (citation needed) but even if it did, the networks that it created could not find anything that wasn't already in the data you give them, and that data would determine what they knew.

so architecture doesn't matter -- to the results, but of course it does matter for operational purposes: you could emulate the hyper turing oracle by just iterating through every possible assignment of weights and choosing the one with the lowest error, and you could implement this brute force algorithm on a regular computer today, but it would take longer than a universe of universes to terminate for a network of any reasonable size.

a smarter architecture lets you train larger networks on bigger training sets with less time and power usage, so architectural improvements allow you to take further steps towards what the perfect minimal function would return for the given input, but no better than that!

19 notes · View notes

understandingactivedirectory · 7 months

Text

Exploring Kerberos and its related attacks

Introduction

In the world of cybersecurity, authentication is the linchpin upon which secure communications and data access rely. Kerberos, a network authentication protocol developed by MIT, has played a pivotal role in securing networks, particularly in Microsoft Windows environments. In this in-depth exploration of Kerberos, we'll delve into its technical intricacies, vulnerabilities, and the countermeasures that can help organizations safeguard their systems.

Understanding Kerberos: The Fundamentals

At its core, Kerberos is designed to provide secure authentication for users and services over a non-secure network, such as the internet. It operates on the principle of "need-to-know," ensuring that only authenticated users can access specific resources. To grasp its inner workings, let's break down Kerberos into its key components:

1. Authentication Server (AS)

The AS is the initial point of contact for authentication. When a user requests access to a service, the AS verifies their identity and issues a Ticket Granting Ticket (TGT) if authentication is successful.

2. Ticket Granting Server (TGS)

Once a user has a TGT, they can request access to various services without re-entering their credentials. The TGS validates the TGT and issues a service ticket for the requested resource.

3. Realm

A realm in Kerberos represents a security domain. It defines a specific set of users, services, and authentication servers that share a common Kerberos database.

4. Service Principal

A service principal represents a network service (e.g., a file server or email server) within the realm. Each service principal has a unique encryption key.

Vulnerabilities in Kerberos

While Kerberos is a robust authentication protocol, it is not immune to vulnerabilities and attacks. Understanding these vulnerabilities is crucial for securing a network environment that relies on Kerberos for authentication.

1. AS-REP Roasting

AS-REP Roasting is a common attack that exploits weak user account settings. When a user's pre-authentication is disabled, an attacker can request a TGT for that user without presenting a password. They can then brute-force the TGT offline to obtain the user's plaintext password.

2. Pass-the-Ticket Attacks

In a Pass-the-Ticket attack, an attacker steals a TGT or service ticket and uses it to impersonate a legitimate user or service. This attack can lead to unauthorized access and privilege escalation.

3. Golden Ticket Attacks

A Golden Ticket attack allows an attacker to forge TGTs, granting them unrestricted access to the domain. To execute this attack, the attacker needs to compromise the Key Distribution Center (KDC) long-term secret key.

4. Silver Ticket Attacks

Silver Ticket attacks target specific services or resources. Attackers create forged service tickets to access a particular resource without having the user's password.

Technical Aspects and Formulas

To gain a deeper understanding of Kerberos and its related attacks, let's delve into some of the technical aspects and cryptographic formulas that underpin the protocol:

1. Kerberos Authentication Flow

The Kerberos authentication process involves several steps, including ticket requests, encryption, and decryption. It relies on various cryptographic algorithms, such as DES, AES, and HMAC.

2. Ticket Granting Ticket (TGT) Structure

A TGT typically consists of a user's identity, the requested service, a timestamp, and other information encrypted with the TGS's secret key. The TGT structure can be expressed as:

3. Encryption Keys

Kerberos relies on encryption keys generated during the authentication process. The user's password is typically used to derive these keys. The process involves key generation and hashing formulas.

Mitigating Kerberos Vulnerabilities

To protect against Kerberos-related vulnerabilities and attacks, organizations can implement several strategies and countermeasures:

1. Enforce Strong Password Policies

Strong password policies can mitigate attacks like AS-REP Roasting. Ensure that users create complex, difficult-to-guess passwords and consider enabling pre-authentication.

2. Implement Multi-Factor Authentication (MFA)

MFA adds an extra layer of security by requiring users to provide multiple forms of authentication. This can thwart various Kerberos attacks.

3. Regularly Rotate Encryption Keys

Frequent rotation of encryption keys can limit an attacker's ability to use stolen tickets. Implement a key rotation policy and ensure it aligns with best practices.

4. Monitor and Audit Kerberos Traffic

Continuous monitoring and auditing of Kerberos traffic can help detect and respond to suspicious activities. Utilize security information and event management (SIEM) tools for this purpose.

5. Segment and Isolate Critical Systems

Isolating sensitive systems from less-trusted parts of the network can reduce the risk of lateral movement by attackers who compromise one system.

6. Patch and Update

Regularly update and patch your Kerberos implementation to mitigate known vulnerabilities and stay ahead of emerging threats.

4. Kerberos Encryption Algorithms

Kerberos employs various encryption algorithms to protect data during authentication and ticket issuance. Common cryptographic algorithms include:

DES (Data Encryption Standard): Historically used, but now considered weak due to its susceptibility to brute-force attacks.

3DES (Triple DES): An improvement over DES, it applies the DES encryption algorithm three times to enhance security.

AES (Advanced Encryption Standard): A strong symmetric encryption algorithm, widely used in modern Kerberos implementations for better security.

HMAC (Hash-based Message Authentication Code): Used for message integrity, HMAC ensures that messages have not been tampered with during transmission.

5. Key Distribution Center (KDC)

The KDC is the heart of the Kerberos authentication system. It consists of two components: the Authentication Server (AS) and the Ticket Granting Server (TGS). The AS handles initial authentication requests and issues TGTs, while the TGS validates these TGTs and issues service tickets. This separation of functions enhances security by minimizing exposure to attack vectors.

6. Salting and Nonces

To thwart replay attacks, Kerberos employs salting and nonces (random numbers). Salting involves appending a random value to a user's password before hashing, making it more resistant to dictionary attacks. Nonces are unique values generated for each authentication request to prevent replay attacks.

Now, let's delve into further Kerberos vulnerabilities and their technical aspects:

7. Ticket-Granting Ticket (TGT) Expiry Time

By default, TGTs have a relatively long expiry time, which can be exploited by attackers if they can intercept and reuse them. Administrators should consider reducing TGT lifetimes to mitigate this risk.

8. Ticket Granting Ticket Renewal

Kerberos allows TGT renewal without re-entering the password. While convenient, this feature can be abused by attackers if they manage to capture a TGT. Limiting the number of renewals or implementing MFA for renewals can help mitigate this risk.

9. Service Principal Name (SPN) Abuse

Attackers may exploit misconfigured SPNs to impersonate legitimate services. Regularly review and audit SPNs to ensure they are correctly associated with the intended services.

10. Kerberoasting

Kerberoasting is an attack where attackers target service accounts to obtain service tickets and attempt offline brute-force attacks to recover plaintext passwords. Robust password policies and regular rotation of service account passwords can help mitigate this risk.

11. Silver Ticket and Golden Ticket Attacks

To defend against Silver and Golden Ticket attacks, it's essential to implement strong password policies, limit privileges of service accounts, and monitor for suspicious behavior, such as unusual access patterns.

12. Kerberos Constrained Delegation

Kerberos Constrained Delegation allows a service to impersonate a user to access other services. Misconfigurations can lead to security vulnerabilities, so careful planning and configuration are essential.

Mitigation strategies to counter these vulnerabilities include:

13. Shorter Ticket Lifetimes

Reducing the lifespan of TGTs and service tickets limits the window of opportunity for attackers to misuse captured tickets.

14. Regular Password Changes

Frequent password changes for service accounts and users can thwart offline attacks and reduce the impact of credential compromise.

15. Least Privilege Principle

Implement the principle of least privilege for service accounts, limiting their access only to the resources they need, and monitor for unusual access patterns.

16. Logging and Monitoring

Comprehensive logging and real-time monitoring of Kerberos traffic can help identify and respond to suspicious activities, including repeated failed authentication attempts.

Kerberos Delegation: A Technical Deep Dive

1. Understanding Delegation in Kerberos

Kerberos delegation allows a service to act on behalf of a user to access other services without requiring the user to reauthenticate for each service. This capability enhances the efficiency and usability of networked applications, particularly in complex environments where multiple services need to interact on behalf of a user.

2. Types of Kerberos Delegation

Kerberos delegation can be categorized into two main types:

Constrained Delegation: This type of delegation restricts the services a service can access on behalf of a user. It allows administrators to specify which services a given service can impersonate for the user.

Unconstrained Delegation: In contrast, unconstrained delegation grants the service full delegation rights, enabling it to access any service on behalf of the user without restrictions. Unconstrained delegation poses higher security risks and is generally discouraged.

3. How Delegation Works

Here's a step-by-step breakdown of how delegation occurs within the Kerberos authentication process:

Initial Authentication: The user logs in and obtains a Ticket Granting Ticket (TGT) from the Authentication Server (AS).

Request to Access a Delegated Service: The user requests access to a service that supports delegation.

Service Ticket Request: The user's client requests a service ticket from the Ticket Granting Server (TGS) to access the delegated service. The TGS issues a service ticket for the delegated service and includes the user's TGT encrypted with the service's secret key.

Service Access: The user presents the service ticket to the delegated service. The service decrypts the ticket using its secret key and obtains the user's TGT.

Secondary Authentication: The delegated service can then use the user's TGT to authenticate to other services on behalf of the user without the user's direct involvement. This secondary authentication occurs transparently to the user.

4. Delegation and Impersonation

Kerberos delegation can be seen as a form of impersonation. The delegated service effectively impersonates the user to access other services. This impersonation is secure because the delegated service needs to present both the user's TGT and the service ticket for the delegated service, proving it has the user's explicit permission.

5. Delegation in Multi-Tier Applications

Kerberos delegation is particularly useful in multi-tier applications, where multiple services are involved in processing a user's request. It allows a front-end service to securely delegate authentication to a back-end service on behalf of the user.

6. Protocol Extensions for Delegation

Kerberos extensions, such as Service-for-User (S4U) extensions, enable a service to request service tickets on behalf of a user without needing the user's TGT. These extensions are valuable for cases where the delegated service cannot obtain the user's TGT directly.

7. Benefits of Kerberos Delegation

Efficiency: Delegation eliminates the need for the user to repeatedly authenticate to access multiple services, improving the user experience.

Security: Delegation is secure because it relies on Kerberos authentication and requires proper configuration to work effectively.

Scalability: Delegation is well-suited for complex environments with multiple services and tiers, enhancing scalability.

In this comprehensive exploration of Kerberos, we've covered a wide array of topics, from the fundamentals of its authentication process to advanced concepts like delegation.

Kerberos, as a network authentication protocol, forms the backbone of secure communication within organizations. Its core principles include the use of tickets, encryption, and a trusted third-party Authentication Server (AS) to ensure secure client-service interactions.

Security is a paramount concern in Kerberos. The protocol employs encryption, timestamps, and mutual authentication to guarantee that only authorized users gain access to network resources. Understanding these security mechanisms is vital for maintaining robust network security.

Despite its robustness, Kerberos is not impervious to vulnerabilities. Attacks like AS-REP Roasting, Pass-the-Ticket, Golden Ticket, and Silver Ticket attacks can compromise security. Organizations must be aware of these vulnerabilities to take appropriate countermeasures.

Implementing best practices is essential for securing Kerberos-based authentication systems. These practices include enforcing strong password policies, regular key rotation, continuous monitoring, and employee training.

Delving into advanced Kerberos concepts, we explored delegation – both constrained and unconstrained. Delegation allows services to act on behalf of users, enhancing usability and efficiency in complex, multi-tiered applications. Understanding delegation and its security implications is crucial in such scenarios.

Advanced Kerberos concepts introduce additional security considerations. These include implementing fine-grained access controls, monitoring for unusual activities, and regularly analyzing logs to detect and respond to security incidents.

So to conclude, Kerberos stands as a foundational authentication protocol that plays a pivotal role in securing networked environments. It offers robust security mechanisms and advanced features like delegation to enhance usability. Staying informed about Kerberos' complexities, vulnerabilities, and best practices is essential to maintain a strong security posture in the ever-evolving landscape of cybersecurity.

#cybersecurity #active directory #kerberos #windows os #cyberattack

12 notes · View notes