Jump to content

Welcome to noName.zone
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. If you already have an account, login here - otherwise create an account for free today!
Photo

How it works: integrity protection in cryptography (part 1)


1 reply to this topic

#1
QuickBreakdown

QuickBreakdown

    0100100101

  • Administrators
  • 898 posts
  • Country: Country Flag
Hello guys,
 
I think it would be cool to share some common concepts about the Internet and your computer with you.
Not only do I think they are fun to learn, but you use these every day. In part 1 (this post) I would like to explain some cryptographic fundamentals.
We will work towards the concept of SSL certificates. They are grounded in integrity protection and digital signatures. Loosely defined, integrity means something is:
  • Unchanged
  • Authentic (only from original/trusted sources)
  • Indisputable (the person who sent the message cannot dispute this fact)
Hashing functions (unchanged)
To understand this concept we first need to look at what a hash function is. Simply put, it is a mathematical function that always produces the same output based on an input.
It is 'deterministic'. More importantly, it is one way (cannot be reversed), has a fixed length output and changes atleast 50% when one part of the input is changed.
 
Spoiler


Example hashing algorithms are:
  • MD5 (128 bit, very old, insecure)
  • SHA1 (160 bit, insecure)
  • SHA256, SHA512, etc.
An example of a hash:
  • nonam -> 7245C94212D6C45B1A7F83C08C62F053
  • noname -> 499DDAAD9DF107BF7107A3E2C0064800
Using a hash like SHA256 (secure) we can verify that contents of for example, a file, have not been changed.
You can see this often when you download a file from the Internet, it will include a hash for you to check against.

Spoiler

 
Message authentication code (authenticity)
How do we verify that the person who sends a message through the Internet is someone we expect it to be?
Lets go back to the hashing algorithm we just looked at. Anyone can generate a hash for a message. There is no way to verify this!
Now take a look at the following picture.
 
Spoiler

Generating an (unsafe) 'message authentication code' (MAC) is relatively simple:
  • Create a hash of the text or document like before
  • Encrypt this hash using a symmetric algorithm (AES, DES, 3DES, etc.)
A symmetric encryption algorithm is an algorithm where both parties have a preshared key (PSK), which they use to encrypt and decrypt a message.
What is the point of this? Well, since in theory only trusted parties have the preshared key, the message is 'authenticated' to be from a known source.
In addition to that, after decryption, the hash is compared to check whether the message was changed!
In practice, preshared keys are almost never used because of scalability issues and risk of compromise.
 
Note: if you want a proper and fast way of using MAC in practice than have a look at 'HMAC' for further reference.
 
Next up ...
Digital signatures. We didn't yet discuss how to make a message indisputable.
As you can imagine, everyone can create a hash of a message and all trusted parties can create a message authentication code.
Suppose we have 5 parties, how can we be sure that one of the messages is specifically from party C?
This is something we will explore further in the next post: public key cryptography and how it is applied, in combination with hashing, to SSL certificates in your browser.
 
And you?
I'd love to hear your feedback, thoughts and knowledge level on the subject.
Hope to see you in the next post.
 
Spoiler

signature.png

#2
I N V A L I D

I N V A L I D
  • Forum user
  • 10 posts

Hi QBD,

 

First of all, your article is amazing, atleast for those who understands bit of tech.

 

I'm not expert in this field any way I'm going to put my views.

 

Consistent hashing is being used almost everywhere, in operating systems, webservers, load balancers, databases, indexes so ppl can jump directly on a row of data even if there are trillions of rows of data, and most importantly in the cookies that are set by noname.zone on my browser ;)

 

Having some terrible history with md5(crafted dictionary attacks), I always use bcrypt.

 

As far as I know bcrypt has following advantages:

 

1. It enforces you to use a key for encryption. So if someone wants to pass a message the so-called pre-shared key become a-must-pre-shared key.

 

2. Resulting hash can be easily fit in less than 60 characters. When someone is designing a operating system or atleast database 60 characters is the minimum and maximum length of memory where neither security nor space is compromised. Why 60? long story short, it's long enough to prevent from brute attacks and small enough to fit inside IP header, cookie or 64 byte memory block.

 

3. It's used in UNIX password system. If someone has used it for a operating system then it def. has some pros over the other algorithms ;)

 

What you said about md5 is absolutly true, I can forgive sha1 but md5 I just cannot resist. It's terrible and can sunk your ship before you even set to sail. Most of the new developers still store the passwords using md5. I'm not saying that it's all bad, it's fast, consistent and one-way thus fits the criteria of hashing algorithm. But it's def. outdated because of it's limitations in respect of security.

 

Apart from this,

A whole lot to learn from your post, I would love to see how you are going to secure my network channel ;)

 

Edit:

I'm sorry I thought it's recent as appearing on second in tech, I just bumped into an old article by mistake, lol

 

Thank you


Edited by I N V A L I D, 04 June 2020 - 01:32 PM.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users