Discover Top Posts Tagged with #encryption and decryption in c source code

Popular Recent

Hello! Do all people on one federation server see all the shared information, or are you able to pick and choose who sees what?

Example:

System A and System B are both friends with C, but not friends with each other. C creates a server for all 3 of them, so C can see both of their information. Can System A and System B therefore see each other's information?

Also I don't exactly know how federation works so correct me if my understanding of how the server sharing works is wrong please :)

In this situation, friend C would be privy to the shared data of both parties. System A and System B cannot see each other’s details. I will detail the typical server model, versus federated, vs ours.

With a typical server, the server is the trusted party. It performs tasks for users after validating that they have permissions, and it manages the data however it sees fit. Often a server will have a database of user logins, a database of user permissions, and a database of user data. To check if a user is who they say they are, it requests they login and checks the credentials they provide against those stored. To check if a user has permission to do something, the server takes the user id and checks its permissions in a table/database. Same with user data. The server functions like a clerk or secretary, they provide the service and you must trust how they do so. Things like password hashing or data encryption are done to secure data in the case of a breach, like locking cabinets & drawers in an office, but the server typically has access. This is why something like a user password reset or account recovery is possible — from the perspective of the server, these things can be arbitrarily changed.

With federation, you retain the same model, but you diversify the implementation. With a centralized service, like Instagram, one group controls the servers. If you don’t trust Meta, you cannot go elsewhere. With federation, a party would take the server & app code to make a protocol any group can use (they may also provide their source code). This means that if users don’t trust Group A (ie, they suspect they’ll try to train AI on user data) they can only use Group B’s servers. They still need to trust Group B, but they have diversity of choice. There can also be diversity of implementation, ie two different Groups can make different apps that connect to the same server. Consider something like Email, where there are multiple providers and receivers to choose from. An example of a federated alternative to Instagram is something like Pixelfed.

We take that a step further, by treating the server as untrusted. The reasoning is that we’re trying to deploy quickly and en masse. There’s not significant time for users to develop trust around new entities. So, centralizing trust even with a variety of groups to choose from is a gamble. We also lack immense interest in personally storing user data, or running the backup/sharing services. If the funds become available we will, but we wanted to open it up. The solution we thought of was removing (or dampening) the need for trust.

The server does not have a user’s login information. Instead, the user uses their encryption keys — a user has a public key that can encrypt things, and a private key that can decrypt things. The user shares their public key with the server. If the server wants to verify a user, it generates a secret, let’s say a random sentence, and encrypts it with the user’s public key. Then, it asks the party claiming to be a user what the secret is, given the encrypted message. If the party on the other end can answer correctly, it means they either have the (private) decryption key, or had a lucky guess. This process is called a challenge. This also means a user can upload encrypted volumes to the server, and the server can be sure it’s the user without knowing what’s in the volumes. A similar process happens for sharing with other users.

When a Friend wants to download data, another process is needed. First, the Friend can get the users public key. The server knows what volumes the user can request, and will only serve those volumes. But more importantly, the user has another key — the VEK — which encrypts individual volumes. Without this, even a user who has the volumes can’t read them (this protects against a server that implements sharing poorly, ie). The System can provide the Friend their VEK with a few layers of security. First is TLS, just normal website encryption. This protects against people watching the connection, but the server can decrypt this. However, the Friend and System can securely talk by exchanging keys.

Imagibe encryption like putting something in a locked box. Your public key is a lock that only opens to the last key used to make it, and your private key is the actual key to unlock it. You can copy your lock or your key, and both you and your friend have your own versions. You want to send messages the server can’t read, and the server is an armored car.

If your friend has your lockbox, which everyone has because it’s public, they can put a copy of their key in it. They send the box to you, the only person who can unlock it. You unlock the box and take out the copy of your friend’s key, which you combine with a copy of yours to create a new key, say A+C. You can then lock the box using your friends key, and send it to them. Your friend, C, did the same thing with System B, but they created the new key B+C. Your friend never saw your private key, A, so they can’t solve your challenges or make new keys using yours. The server never saw any of the keys, and so has no idea what was exchanged.

Now you have a shared way to securely message, and can exchange your VEK for the volumes your friend has.

The friend could do some things, like save the VEK to decrypt data even after their permission was revoked. But our app doesn’t support this (we actively try to prevent it), the relay server’s enforcement of permissions acts as a second layer of defense, and the user being able to re-encrypt volumes with a new VEK acts as another (though this isn’t presently implemented).

The federated relay acts as an independent party to almost all operations. It’s expected to fulfill tasks, and the security model assumes it will try to snoop on data — which is why all data is encrypted even to the server.

The federation model is not what causes the security behavior, that’s instead something adjacent to a zero-trust model. Federation is just the independent servers model. We’ve combined them. Hopefully this provides some explanation. We’ll create a blog post at some point to describe it more formally! And hopefully with pictures.

#asks

Tools of the Trade for Learning Cybersecurity

I created this post for the Studyblr Masterpost Jam, check out the tag for more cool masterposts from folks in the studyblr community!

Cybersecurity professionals use a lot of different tools to get the job done. There are plenty of fancy and expensive tools that enterprise security teams use, but luckily there are also lots of brilliant people writing free and open-source software. In this post, I'm going to list some popular free tools that you can download right now to practice and learn with.

In my opinion, one of the most important tools you can learn how to use is a virtual machine. If you're not already familiar with Linux, this is a great way to learn. VMs are helpful for separating all your security tools from your everyday OS, isolating potentially malicious files, and just generally experimenting. You'll need to use something like VirtualBox or VMWare Workstation (Workstation Pro is now free for personal use, but they make you jump through hoops to download it).

Below is a list of some popular cybersecurity-focused Linux distributions that come with lots of tools pre-installed:

Kali is a popular distro that comes loaded with tools for penetration testing

REMnux is a distro built for malware analysis

honorable mention for FLARE-VM, which is not a VM on its own, but a set of scripts for setting up a malware analysis workstation & installing tools on a Windows VM.

SANS maintains several different distros that are used in their courses. You'll need to create an account to download them, but they're all free:

Slingshot is built for penetration testing

SIFT Workstation is a distro that comes with lots of tools for digital forensics

These distros can be kind of overwhelming if you don't know how to use most of the pre-installed software yet, so just starting with a regular Linux distribution and installing tools as you want to learn them is another good choice for learning.

Free Software

Wireshark: sniff packets and explore network protocols

Ghidra and the free version of IDA Pro are the top picks for reverse engineering

for digital forensics, check out Eric Zimmerman's tools - there are many different ones for exploring & analyzing different forensic artifacts

pwntools is a super useful Python library for solving binary exploitation CTF challenges

CyberChef is a tool that makes it easy to manipulate data - encryption & decryption, encoding & decoding, formatting, conversions… CyberChef gives you a lot to work with (and there's a web version - no installation required!).

Burp Suite is a handy tool for web security testing that has a free community edition

Metasploit is a popular penetration testing framework, check out Metasploitable if you want a target to practice with

SANS also has a list of free tools that's worth checking out.

Programming Languages

Knowing how to write code isn't a hard requirement for learning cybersecurity, but it's incredibly useful. Any programming language will do, especially since learning one will make it easy to pick up others, but these are some common ones that security folks use:

Python is quick to write, easy to learn, and since it's so popular, there are lots of helpful libraries out there.

PowerShell is useful for automating things in the Windows world. It's built on .NET, so you can practically dip into writing C# if you need a bit more power.

Go is a relatively new language, but it's popular and there are some security tools written in it.

Rust is another new-ish language that's designed for memory safety and it has a wonderful community. There's a bit of a steep learning curve, but learning Rust makes you understand how memory bugs work and I think that's neat.

If you want to get into reverse engineering or malware analysis, you'll want to have a good grasp of C and C++.

Other Tools for Cybersecurity

There are lots of things you'll need that aren't specific to cybersecurity, like:

a good system for taking notes, whether that's pen & paper or software-based. I recommend using something that lets you work in plain text or close to it.

general command line familiarity + basic knowledge of CLI text editors (nano is great, but what if you have to work with a system that only has vi?)

familiarity with git and docker will be helpful

There are countless scripts and programs out there, but the most important thing is understanding what your tools do and how they work. There is no magic "hack this system" or "solve this forensics case" button. Tools are great for speeding up the process, but you have to know what the process is. Definitely take some time to learn how to use them, but don't base your entire understanding of security on code that someone else wrote. That's how you end up as a "script kiddie", and your skills and knowledge will be limited.

Feel free to send me an ask if you have questions about any specific tool or something you found that I haven't listed. I have approximate knowledge of many things, and if I don't have an answer I can at least help point you in the right direction.

#studyblrmasterpostjam #studyblr #masterpost #cybersecurity #late post bc I was busy yesterday oops lol #also this post is nearly a thousand words #apparently I am incapable of being succinct lmao

Password Manager Part 1

So the other day I was thinking about what else I could do to make my cyber life safer. So I started to looking into a Password Manager. Now you can buy a subscription to a password manager service and there are some good sites out there, but the problem is two things the subscription and security.

By security I mean you look around and you see leaks every where. Corporations getting hacked or they use the info to sale your info and all the user data is under there control. All it would take is someone to hack the password manages and then all the passwords could be out there and your rushing to change everything before they get in.

I don't have the money to do something like that, so I started to dig into making my own Password Manager using Python.I started looking into what I would need.

First would be encryption, one of the standards of the cybersecurity world. Using a mix of hashing through the SHA256 algorithm, and always salting your hashes you can make your stored passwords even more secure.

The code

# Setting up crytogtaphy from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC from cryptography.hazmat.backends import defult_backend import base64

def derive_encryption_key(master_password, salt): kdf = PBKDF2HMAC( algorithm=hashes.SHA256(), length=32, salt=salt, iterations=100000, backend=defult_backend() ) key = base64.urlsafe_b64encode(kdf.derive(master_oasswird.encode())) return key

Then encryption and decryption, the method of the program will use to keep the passwords encrypted and then decryption when they need to be executed. Writing this code was more challenging but there some amazing resources out there. With quick google searches you can find them.

The Code

# Encryption and Decrptions from cryptography.fernet import Fernet

def encrypt_password(password, key): fernet = Fernet(key) encrypted_password = fernet.encrypt(password.encode()) return encrypted_password

def decrypt_password(encrytped_password, key): fernet = fernet(key) decrypt_password = fernet.decrypt(encrypted_password).decode() return decrypted_password

Next up I wanted Random Password generation, at least 12 chars long, with letters, numbers and special chars.

The Code

# password generation import string import random

def generate_secure_password(length=12): char_pool = string.ascii_letters + string.digits + string.punctuation password = ''.join(random.choice(char_pool) for _ in range(length)) return password

Finally it would be needing a data base to store the passwords. Through googling, and research. I would need to set up a SQL Data base. This would be something new for me. But first I could set up the code and the key for the user. Later I will add the SQL data base.

Now part of this would be setting up a Master Password and user name. This worried me abet, because anybody could just hop in and take a look at the code and see the Master Password and then get access to all my passwords and such. So to keep your code safe, it is all about restricting your code. Location, keep your code in a safe locked files, away from prying eyes and encrypted, and access to the source code should be restricted to just you and who ever you trust.

The Code

# Seting up SQL database. def setup_database(): conn = sqlite3.connect('users.db') c = conn.cursor() c.execute('''CREATE TABLE IF NOT EXISTS Uer_keys (user_id TEXT PRIMARY KEY, key BLOB)''') conn.comit() conn.close()

def main(): # setup database setup_database()

#create a key for the user master_password = input("Enter your master password: ") salt = b' some_salt' # Generate secure salt for each user key = derive_encryption_key(master_password, salt)

#Simulate user intreaction user_id = "[email protected]" #user ID user_password = "Password1234" #user password to encrypt

# Encrypt the users password encrypt_password = encrypt_password(user_password, key) print(f"decrypted password for {user_id}; {decrypt_password}")

# Placeholder for intrgrtating the password storage and retriecal logic # This would inculde calls to interact with the SQL database.

if __name__ == "__main__": main()

Now I have much more to do to the program, I need to set up a SQL data base for storage this will be its own can of worms. Learning SQL will be a new challenge for me.

Also I wanted to add more features to the program, I was thinking about setting up an auto fill feature. Now the program will just display the requested password and you have to manually put it in. I want to see if there will be a way to auto fill it.

So stay tuned as I do more research.

#IT #cybersecurity #password manager #Python

In Game:

The popular Caesar cipher code format is widely attributed to have been designed by Caesar, hence its name. The code has often been used in the Assassin's Creed series, most commonly in secret messages left behind by Clay Kaczmarek as Rifts.

Rifts appeared to be breaks in the programming of memories within the Animus, which could be seen using Eagle Vision. Each of the ten rifts were found on key landmarks throughout Rome, and concealed Clay's cluster puzzles.

Rifts were the equivalent of Glyphs, but instead of revealing a second Truth video, they simply relayed the message "The miracle is in the execution" over the apparent ultrasound of an unborn child, along with the inclusion of an executable file.

Unlike Glyphs, Rifts could not be seen or accessed without the use of Eagle Vision. Ezio Auditore da Firenze had to grab the edge of a Rift, whilst using Eagle Vision, and climb into it.

Various hidden messages such as coded numbers and letters, music notes and Morse code appeared in the Rifts, which when deciphered, explained Abstergo Industries' rise to power.

In Real Life:

The Caesar cipher is one of the earliest known and simplest ciphers. It is a type of substitution cipher in which each letter in the plaintext is 'shifted' a certain number of places down the alphabet. For example, with a shift of 1, A would be replaced by B, B would become C, and so on. The method is named after Julius Caesar, who apparently used it to communicate with his generals, although evidence exists that Julius Caesar also used more complicated systems.

More complex encryption schemes such as the Vigenère cipher employ the Caesar cipher as one element of the encryption process. The widely known ROT13 'encryption' is simply a Caesar cipher with an offset of 13. The Caesar cipher offers essentially no communication security, and it will be shown that it can be easily broken even by hand.

(Image source)

To pass an encrypted message from one person to another, it is first necessary that both parties have the 'key' for the cipher, so that the sender may encrypt it and the receiver may decrypt it. For the caesar cipher, the key is the number of characters to shift the cipher alphabet.

Caesar’s nephew, Augustus, also used the cipher, but with a right shift of one, and it did not wrap around to the beginning of the alphabet.

It is unknown how effective the Caesar cipher was at the time, but it is likely to have been reasonably secure, not least because most of Caesar's enemies would have been illiterate and others would have assumed that the messages were written in an unknown foreign language. There is no record at that time of any techniques for the solution of simple substitution ciphers. The earliest surviving records date to the 9th century works of Al-Kindi in the Arab world with the discovery of frequency analysis.

A Caesar cipher with a shift of one is used on the back of the mezuzah to encrypt the names of God. This may be a holdover from an earlier time when Jewish people were not allowed to have mezuzot. The letters of the cryptogram themselves comprise a religiously significant "divine name" which Orthodox belief holds keeps the forces of evil in check.

In the 19th century, the personal advertisements section in newspapers would sometimes be used to exchange messages encrypted using simple cipher schemes.