Scribd Logo
Upload

Welcome to Scribd!

  • 15 views

    Report

    Uploaded by

    reagan omondi

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Report

    Uploaded by

    reagan omondi
    15 views11 pages

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    15 views11 pages

    Report

    Uploaded by

    reagan omondi

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    You are on page 1of 11

    Introduction

    So within this project We will Develop a real-time secure chat application from
    scratch like Whats-App with end-to-end encryption. The project will cover:
     Intrinsic Socket Programming
     Real-Time System
     End-to-end Encryption

    The secure chat will provide the following:


     MultiUser group chat application
     Users can choose between the different encryption modes:
    - Single key (DES)
    - Two keys (RSA, EL GAMAL)
     TTP (Third Trusted Party) which facilitates interactions between two parties
    who both trust the third party

    The Technology Stack used here will be :


     Python as the server-side language
     T-kinter library for UI
     Socket library for real-time message exchange
    System Design:
    It was challenging to make the app real-time majprly because the user needs to
    be kept updated constantly with any activity happening as soon as possible.

    Here we can describe what is happening in the system in simple steps:


    - server will start at the HOST IPv4 at the chosen PORT
    - client will tries to connect to the server
    - server accept the client connection
    - server generates session key for the accepted client
    - client sends username to the server
    - client and server start listener thread
    - user sends a message (after encryption using any of one of the encryption
    modes)
    - server sends the cipher to all clients even the sender
    - client receives the cipher (then start decryption)
    - server still receives message from another client
    - server keep listening for any new client connections
    - server responsible to send and receive messages contain information like
    (username, message, required keys)
    (Data Encryption Standard):
    Block ciphers, like D.E.S., encrypt data in blocks of 64 bits each. This implies that 64 bits of plain
    text are fed into DES, which generates 64 bits of cipher text. Both encryption and decryption
    employ the same algorithm and key.
    We split the massage into several blocks when the message is longer than 64 bits. Let's talk
    about the steps in the algorithm:

    1) An initial Permutation (IP) function is used with the 64-bit plain text.

    2) The simple text undergoes the first permutation.

    3) The initial permutation (IP) then produces the Left Plain Text and Right Plain Text, which are
    the two parts of the permuted block.

    4) There are now 16 rounds of encryption for both the right and left sides.

    1) In this process produces 64-bit cipher-text as a result, then repeat the


    steps again for the rest of message blocks.
    DES Algorithm Run:

    RSA – (Rivest-Shamir-Adleman):
    R.S.A algorithm is asymmetric cryptography algorithm. Asymmetric actually
    means that it works on two different keys i.e., Public Key and Private Key. As the
    name describes that the Public Key is given to everyone and Private key is kept
    private.
    Let’s discuss the algorithm steps:
    1) Key generation:
    1.1) Choose two prime numbers p and q
    1.2) Calculate n=p*q
    1.3) Calculate φn=( p−1)(q−1)
    1.4) Select an integer where 1<e< φn and GCD (e, φn )=1 and they co
    primes (public key with n)
    1.5) d=e−1 (mod φn) where d is modular multiplicative inverse of e mod φn
    (private key with n)

    2) Encryption:
    Turn the message into cipher text by using modular exponentiation
    C=me (mod n)

    3) Decryption:
    Turn the cipher text back into plain text by using private key exponent
    m=c d (mod n)

    4)
    El Gamal Cryptography:
    The Diffie-Hellman key exchange serves as the foundation for the El-Gamal encryption system,
    an asymmetric key encryption mechanism in public-key cryptography. It was initially described
    by Taher Elgamal in 1985. ElGamal encryption is used in the most recent PGP versions, the free
    GNU Privacy Guard program, and other cryptograms.

    Let’s discuss the algorithm steps:


    5) Key generation:
    2.1) Choose one prime number q
    2.2) Finding primitive root of q a
    2.3) Generating randomly private keyXA must be less than q-1
    2.4) Generating key YA  YA=aXA mod q
    2.5) Public key= [q, a, YA]

    6) Encryption:
     Turn the message into two different ciphertext (C1,C2) by using M as
    a pair of integers where
    • C1 = ak mod q ; C2 = KM mod q

    7) Decryption:
    Changing the cipher key(C1, C2) to plain text by finding the
    recovering key where
    recovering key K as K = C1xA mod q
    Then using the key to get the plain text M
    computing M as M = C2 K-1 mod q
    ElGamal Cryptography run:

    The Chat Application Demo:

    GUI ( 2 Clients Chatting )


    THE SECURITY OF RSA — VULNERABILITIES CAUSED BY LACK OF FORWARD SECRECY

    Forward secrecy, also known as Perfect Forward Secrecy, ensures


    that the encryption keys used in a session cannot be inferred from
    future compromises, unlike RSA.
    In the hopes of eventually obtaining the server's private keys, the
    attacker, who has successfully installed a packet sniffer in the LAN
    to which the client is connected, patiently logs all encrypted
    interactions between the client and the server. The attacker would
    obviously be able to decode the session key that was transmitted to
    the server encrypted by the client if that were to occur. As you
    might guess, the attacker will be able to decode all of the recorded
    conversations between the client and the server after they have
    worked out the session key.

    ˆ The possibility of an attacker obtaining the private keys of a server


    is not as unlikely as it may seem. Software flaws or dishonest
    personnel may anonymously divulge private keys. The most recent
    instance of how software flaws can make private keys vulnerable to
    theft is the Heartbleed vulnerability, which was found on April 7,
    2014. [For further details on the Heartbleed problem and the
    Heartbeat Extension to the SSL/TLS protocol, see Section 20.4.4 of
    Lecture 20.] ˆ We claim that because the fundamental RSA
    algorithm lacks forward secrecy, it allows the above-described
    exploit to be executed. The seriousness of this vulnerability in a
    particular server-client interaction.

    Finding a way to generate a secret session key without putting it on


    the wire is the answer to this RSA issue. You would naturally say,
    "But that is impossible!!!" in response to this notion. "How can two
    sides share a secret without either mentioning it to the other?" is
    probably what you'll add. But as they say, never undervalue the
    inventiveness of people. The Diffie-Hellman (DH) method, which we
    shall discuss in Lecture 13, is an exceptionally elegant technique
    that allows the creation of a session key without either party
    sending the key to the other.

    DH offers Perfect Forward Secrecy as a result. DH does have a


    drawback, too, as you will see in Lecture 13: it is susceptible to man-
    in-the-middle attacks. When RSA and DH are combined, the result is
    known as DHE-RSA, which provides perfect forward secrecy by using
    RSA for endpoint (such as server) authentication and DH for session
    key exchange.

    Lecture12.pdf (purdue.edu)
    http://paper.ijcsns.org/07_2013/20130702.pdf

    You might also like

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy