coledeman - Tumblr blog

coledeman · 8 years ago

Text

How Public Key Cryptosystems Work

Basic Concept:

A public key cryptosystem, also known as asymmetric key encryption or double key encryption, is a cryptosystem that has 2 keys, a public key and a private key. The public key is used for encryption and the private key is used for decryption. The idea is that its like a combination lock, anyone can lock it, but only the person with the combination (private key) can unlock it. This is were the trick lies, you can give the public key to anyone. The public key is used for “locking” the message. Only the private key can “unlock” it so it must be kept secret.

Public key cryptosystems improve on some of the draw backs of private key cryptosystems. In a private key cryptosystem the key is only useful between one pair of users. If Bob and Alice are using key1 and Bob wants to talk to Trudy, Bob and Trudy must create another key, key2, for just them to use. This also means in a network using a private key system there needs to be n(n-1)/2 keys where n = number of nodes (users or machines or servers). Public key protocols also allow for Integrity, Authentication and non-repudiation through use of Digital Signatures and Certificates. Where private key protocols do not allow Integrity, Authentication and non-repudiation alone.

RSA Algorithm (Example of public keys):

RSA Steps:

Step 1:

Choose 2 large prime numbers p & q (typically 512 digits or larger)

Step 2:

Find their product n, n = p x q.

Step 3:

Find a integer e such that, e < n and e is relatively prime to (p-1)(q-1), that is that (p-1)(q-1) and e have no common factors.

Step 4:

Find the integer d such that ed mod (p-1)(q-1) = 1.

Private Key: (e, n)

Public Key: (d, n)

Encryption Formula: Cipher Text = (plain text)e mod n

Decryption Formula: Plain Text = (Cipher Text)d mod n

RSA Example:

Step 1: Choose 2 large prime numbers p & q (for sake of example they are small)

p = 11 q = 17

Step 2: Find the product of p & q.

n = (p x q) = (11 x 17)

n = 187

Step 3: Find a integer e such that, e < n and e is relatively prime to (p-1)(q-1)

(p – 1)(q – 1) = 160

Done by trial and error:

2, no shares the factor 2 with 160

3, yes, shares no factors and is less than 187.

e = 3

Step 4: Find the integer d such that ed mod (p-1)(q-1) = 1.

We have e = 3 so we must find:

3d mod 160 = 1, that is 3d is a multiple of 160 + 1.

by trial and error we can keep trying multiples of 160, add 1 and check if it is divisible by 3.

161, no not divisible by 3.

321, yes divisible by 3.

therefore 3d = 321

so d = 321/3 = 107.

d = 107

Therefore:

Public Key (e, n): (3, 187)

Private Key (d, n): (107, 187)

Encryption of message = 5 :

Cipher Text = messagee mod n

Cipher Text = (5)3 mod 187

Cipher Text = 125

Decryption:

message = (Cipher Text)d mod n

message = (125)107 mod 187

message = 5

How Public Key Cryptosystems Work was originally published on Cole Talks

#decryption #encryption #network security #public key cryptosystems #RSA #coletalks

0 notes

coledeman · 8 years ago

Text

How IPSEC Works

IPSEC or IP Security is IETF‘s proposal and is touted as the most secure option for building VPNs. Bundled with IPv6, IPSEC is a tunneling protocol for IP that provides per-packet, end-to-end or segment-by-segment protection. It’s highly flexible, supporting a wide variety cryptographic algorithms and allows bundling and nesting of its component protocols. IPSEC also has a very efficient key management and exchange procedure.

Components

Authentication Header (AH)

AH is used for connection-less integrity and authentication of IP packets. It also protects from replay attacks, every packet increases the sequence number by one and numbers are never reused. If it ever runs out of sequence numbers before renegotiating a new security association it triggers a renegotiation.

Authentication Header:

.tg {border-collapse:collapse;border-spacing:0;}.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}.tg .tg-baqh{text-align:center;vertical-align:top}

Next Header Code Header Length Reserved Security Parameters Index (SPI) Sequence Number Authentication Data (Message Digest)

Legend:

Next Header Code (8-bits): Identifies what the next head is if there is one.

Header Length(8-bits): The length of the AH.

Reserved(16-bits): Not currently used.

SPI(32-bits): Arbitrary value which is used (together with the destination IP address) to identify the security association of the receiving party.

Sequence Number (32-bits): An increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks.

Authentication Data(Multiple of 32-bits): A message digest to authenticate the payload.

Encapsulating Security Payload (ESP)

ESP provides origin authenticity, integrity the same as the AH, but ESP also provides confidentiality protection of packets. ESP however is what makes IPSEC useful for VPNs. In tunneling mode ESP take the original packet, encrypts it, and inserts it into a new packet with source and destination IP addresses corresponding to the beginning and end of the tunnel.

ESP Header & Trailer:

Next Header Code Header Length Reserved Security Parameters Index (SPI) Sequence Number Encrypted Payload Authentication Data (Message Digest)

Legend:

Next Header Code (8-bits): Identifies what the next head is if there is one.

Header Length(8-bits): The length of the AH.

Reserved(16-bits): Not currently used.

SPI(32-bits): Arbitrary value which is used (together with the destination IP address) to identify the security association of the receiving party.

Sequence Number (32-bits): An increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks.

Encrypted Payload: the data or packet being encrypted.

Authentication Data(Multiple of 32-bits): A message digest to authenticate the payload.

Everything before the encrypted payload is the ESP header, the trailer is the Authentication data.

Internet Key Exchange (IKE)

IKE is much more involved than the last 2 components. It’s used for securely negotiating encryption methods and exchanging the keys needed.

This protocol is broken into 2 phases.

Phase I:

Overview:

Phase I has 6 messages:

Security Association (SA) messages are sent and negotiated in messages 1 and 2.

Diffie-Hellman exchanges are done in messages 3 and 4. A master key SKEYID is established.

Digital Signatures and certificates are exchanged in message 5 and 6. They are encrypted using SKEYID. The 2 nodes authenticate each other using these.

Message 1: A -> B

Node A sends a packet containing proposals for what encryption and authentication to use.

Each proposal contains:

Encryption Algorithm

Encryption Key length

Authentication algorithm

Authentication Key Length

Key Lifetime

SA lifetime

Cookie containing the hash of (A’s secret + IP of A + timestamp)

Proposal 1 Proposal 2 … Proposal n Cookie A

Message 2: B -> A

Node B sends a message back to A containing the subset of proposals that B accepts along with a Cookie B = hash (B’s secret + B’s IP + timestamp)

Proposal 1 Proposal 2 … Proposal n Cookie A Cookie B

Message 3: A -> B

Node A sends a message to B with information for a Diffie-Hellman Exchange. This exchange is for generating the SKEYID.

(N1)pubB P, g, TA

(N1)pubB: random number encrypted with B’s public key.

P: prime number

g: generator number.

TA: number generated by A in Diffie-Hellman protocol.

Message 4: B -> A

Node A sends a message to B with information for a Diffie-Hellman Exchange. This exchange is for generating the SKEYID.

(N2)pubA P, g, TB

(N2)pubA: random number encrypted with A’s public key.

P: prime number

g: generator number.

TB: number generated by B in Diffie-Hellman protocol.

Message 5: A -> B

A sends it’s digital signature and certificate encrypted by SKEYID. B will decrypt these with SKEYID and uses them to authenticate A.

A’s digital signature A’s Certificate

Message 6: B -> A

B sends it’s digital signature and certificate encrypted by SKEYID. A will decrypt these with SKEYID and uses them to authenticate B.

B’s digital signature B’s Certificate

Phase II:

Overview:

Phase II has 3 messages. Using encrypted packets protected by digital signatures, they do another Diffie-hellman exchange. This generates the secret session key. Data is transfered using the secret session key. Keys are then refreshed every few minutes in Phase II.

All messages until the session key is generated are encrypted with the SKEYID.

Message 1: A -> B

A sends a hash, a random number N3, and the Diffie-Hellman values P, g, TA.

Hash1 n3 P, g, TA

Hash1 = hash(SKEYIDa || N3 || p, g, TA)

B opens message 1, gets P, g, TA and verifies Hash1.

Message 2: B -> A

B sends a hash, a random number N4 and TB.

Hash2 n4 TB

Hash2 = hash(SKEYIDa || N4 || A (IP address) || B (IP address))

A opens message 2, gets TB and verifies Hash2.

Message 3: A -> B

A sends just a Hash3 = (SKEYIDa || N3 || N4 || A || B)

and the final secret session key is = hash(SKEYIDa || Diffie-Hellman Secret || N3 || N4).

All further communications are encrypted with this key until the key expries and they generate a new one using phase 2.

Using for Tunneling

Authentication Header

Packet:

Source Destination Payload

Transport mode:

In transport mode a AH is simply added to insure that the packet cannot be replayed or tampered with. It doesn’t actually provide any encryption.

Source Destination Authentication Header Payload

Tunnel Mode:

In tunnel mode the start and end of the tunnel (essentially a new temporary source and destination) are added and the original source and destination are moved into the packet to be used at the end of the tunnel.

Tunnel Start Tunnel End Authentication Header Source Destination Payload

Encapsulating Security Payload

This is where confidentiality enters the equation. With ESP the payload is encrypted, meaning that when using transport the payload is encrypted and when using tunneling both the original source and destination are encrypted along with the payload. The encryption is determined using IKE. Packet:

Source Destination Payload

Transport Mode:

Transport simply takes the original payload, encrypts it, and adds a ESP header and trailer to the packet.

Source Destination ESP header Payload (now encrypted) ESP trailer

Tunnel Mode:

When in tunnel model an entirely new packet is created and the original packet become the encrypted payload. This is why this Protocol is so secure for VPN usage. Once the packet enters the tunnel you cannot determine anything about it other than the beginning and end of the tunnel. This means a 3rd party can’t even tell what server you were communicating with while your packet is in the tunnel.

Source Destination ESP header Payload (now encrypted) ESP trailer

How IPSEC Works was originally published on Cole Talks

#AH #Authentication Header #Encapsulating Security Payload #ESP #IKE #internet #IPSEC #network security #packet #tunnel #virtual private network #VPN #coletalks

0 notes

coledeman · 8 years ago

Text

Creating a Security Plan

What is a Security Plan?

A Security plan is a a document addressing the security needs of a organization. It’s a “live” document that is periodically reviews and revised.

A good security plan is an official record of current security practices and a blueprint for orderly change to improve these practices. It also gives developers and users a way of measuring the effects of proposed changes, leading to more improvements. This plan should looks to Achieve the 3 Security Goals.

3 Security Goals:

Confidentiality:

Limiting information to only those who are allowed to access it, preventing those who are not. Using techniques such as encryption and access-control.

Integrity

Making sure data is consistant. Using techniques such as error checking, certificates, and digital signatures to make sure data is trustworthy and cannot be altered by a thrid party.

Availability

Availability insures that resources are available and functional, involves things like redundancy and backups.

Contents of a Security Plan:

Policy:

High level statement of organizations security goals. Where the responsibility for security lies and the organizations commitment to security. What is the organization protecting, who is responsible to over see this security and the lengths at which the organization will go for this security.

Current State:

A description of what the current state of security is, listing vulnerabilities to which the system is exposed; who is responsible for protecting what assets; and setting boundaries to those responsibilities. Must be clear who exactly is responsible for what and where their responsibility ends. This leaves no gray areas where responsibilities overlap.

Requirements:

The functional and performance demands on the system to meet the desired level of security. If your security requirements say you need to bio metric identification you’re going to need processing power and equipment to meet this.

Recommendations:

Recommended security techniques and mechanisms that should be put in place to meet the organizations security requirements. Things like password salting and hashing, honey pots, etc.

Accountability:

Who is responsible for each security activity.

Timetable:

When each security goal should be achieved. This help keep the organization on track implementing the security required.

Evaluation Methods:

How to measure the effectiveness of the plan.

Questions to be Addressed:

What needs to be protected? (Inspection)

This can be achieved through Risk Analysis:

Make a formal inventory of all resources (information, software, equipment, algorithms, etc)

Assign ownership of each of these resources (creator, maintainer, user)

Determine value of each resource.

For each resource, list the threats that could cause damage.

Calculate the risk impact, risk probability, risk exposure, and risk leverage of each resource.

Risk Impact (RI): cost to replace resource.

Risk Probability (RP): likely hood of attack on resource.

Risk Exposure (RE): RI x RP = RE.

Risk Leverage (RL): ((RE before security) – (RE after security)) / (cost of security) = RL

When deciding what to use security budget on, protect the resources with the highest RL. The higher the RL the more bang you get for you buck.

How to Protect?

Deploy tools for achieving the 3 security goals for each resource or set of resources, starting with the ones with the highest risk leverage.

How to detect Intrusion?

Detection is all about detecting when an attack has happened, anyone who says their system is 100% secure is either lying or there system is an encrypted CD encased in a block of reinforced concrete buried a km into the earths crust. So you must make sure you can detect when an attack happens.

Some tools and techniques for Detection are:

Signature Analysis:

Comparing log files to the signatures of other attacks. Useful for things like DDoS or detecting brute force attacks etc.

Anomaly Detection:

Look for unusual activities or statistic anomalous behavior.

Dynamic Analysis: (Signature Analysis + Anomaly Detection)

Determine if an attack is underway; tools utilize audit trails and network traffic logs.

Honey Pots:

Sub networks configured with vulnerabilities and not resources of value. Used to study how systems are attacked and identifying attackers that you would want to block from your real resources.

How to React to a attack?

You must have plans in place to react to an attack.

Some Strategies:

Prepare a rapid response team, a team available to be notified 24/7; and given authority to respond to attacks.

Develop a network disconnect plan

Develop rapid recovery procedures (Backup servers, redundant databases etc)

Assess the damage.

Restore information from a trusted backup

Monitor the system for indications of a continued attack.

What to do after an Attack?

You must have procedures in place to reflect on attacks and improve security to prevent them in the future.

Some Steps to Take:

Assemble the information from all involved.

Conduct post-incident briefings to gather information that was not recorded.

Create a technical summary that can be evaluated for the applicability to other systems.

Write and executive summary for upper management to understand the incident’s issues.

Re-evaluate the organizations security plan and make changes.

Creating a Security Plan was originally published on Cole Talks

#attacks #network security #plans #security plan #coletalks

0 notes

coledeman · 8 years ago

Text

Secure Electronic Transaction (SET)

Secure Electronic Transaction (SET) is a protocol designed to securely send credit card transactions over the internet. It was first used by Master Card and Visa, and developed by IBM, Microsoft, Netscape, RSA, Terisa and Verisign. SET provides:

Confidentiality of cardholder account and payment information.

Integrity of the order information, personal information, and payment instructions.

Cardholder Authentication.

Merchant authentication.

Basic Overview:

The cardholder sends a packet containing the Order info (OI) and Payment Info (PO) to the merchant. The merchant uses the OI to determine what you ordered and how you are then sends the PO to the bank for verification. The thing that makes the protocol interesting and useful is that the merchant cannot decrypt your payment info, so you don’t have to trust them with your credit card info, and the bank uses a dual signature specific to the order to verify the payment without needing to see what you are ordering.

Detailed Overview:

Step 1: Creating a Dual Signature

A dual signature is used to link 2 messages that are meant for 2 different recipients. It allows the order information to be verified by the merchant and the payment information to be verified by the payment gateway.

The cardholder takes both the order information and Purchase information and puts them through a hash function to get the Order Information Message Digest and Purchase Information Message Digest. These message digests are fixed length codes created from the contents of the OI and PI that can be used to verify they are correct. The PIMD and OIMD are concatenated together and run through another hash function to create the Purchase Order Message Digest. The POMD is then encrypted using RSA using the customers private key creating the Dual Signature. This way anyone using the customers public key can decrypt it. Since the customer is the only one with their private key it authenticates the Dual signature came from the customer.

Step 2: Cardholder sends Purchase Request

When the cardholder sends the Payment Information (PI) and Order information (OI) to the merchant in the purchase request it first encrypts the PI, Dual signature and Order Information Message Digest (OIMD) using the payment gateway’s public key. It then combines this encrypted data with the Order Information, Payment Information Message Digest and the Dual Signature. Then encrypts this whole package using the merchants public key.

The PI, Dual Signature, and OIMD are combined and encrypted using a symmetric key, the symmetric key is then encrypted with the payment gateways public key so that only the payment gateway can decrypt it. These are both put into a package along with the Payment information message digest, Order information, and an un-encryped copy of the dual signature. This entire package is encrypted using the merchants public key, so that no one can see what is sent except the merchant, maintaining confidentiality of the package and what the cardholder has ordered.

Step 3: Merchant Verifies Purchase Request/Sends PO to Payment Gateway

When the merchant receives the purchase request it must verify the the purchase request is legitimate. If the request is not from the cardholder or has been tampered with it must fail this step. This is what the dual signature is used for. The merchant decrypts the dual signature using the cardholder’s public key (the only thing that can decrypt something encrypted with the cardholder’s private key) to get the POMD (Payment Order Message Digest). Then the merchant uses the payment information message digest to generate a POMD from this information. If the decrypted and generated POMD match it proves the request if from the cardholder (only the card holder would have the correct private key) and hasn’t been tampered (if it had been tampered with, the card information was changed, or the order info had been changed the dual signatures would not match).

After this process the the encrypted payment package and symmetric key are sent to the payment gateway.

Step 4: Payment Gateway Verifies Customer Payment Request

The payment information is received by the payment gateway it must be verified. This process is almost identical to the process in step 3.

The symmetric key is first decrypted using the payment gateway’s private key, this key is then used to decrypt the Payment info (PI), the Order Information message digest (OIMD), and the Dual signature. The Dual Signature is then decrypted to get the POMD. The PI and OIMD are then concatenated and hashed to produce a POMD, if this POMD and the POMD from the dual signature match then the payment is verified.

After the payment gateway verifies the Payment information it confirms there are enough funds for the transaction and sends a confirmation to the merchant. Then the payment gateway transfers funds and sends an invoice to the cardholder.

Secure Electronic Transaction (SET) was originally published on Cole Talks

#computer science #computers #flow charts #internet #network security #protocols #Secure Electronic Transaction #SET #technology #coletalks

1 note · View note

coledeman · 8 years ago

Text

Diffie-Hellman Key Exchange.

Imagine Bob and Alice want to send secret messages to each other and Trudy is trying to read these messages. How can Bob and Alice keep Trudy from eavesdropping on their conversation? The answer is they use an encryption algorithm that has a key. You can picture this as the put the message in a box and use a lock (an encryption algorithm) that has a key. The Diffie-Hellman key exchange algorithm is a set of steps that allows Bob and Alice to both get a copy of the key without the risk of Trudy getting a copy.

The Diffie-Hellman key exchange algorithm is a very clever way to exchange an encryption key between 2 machines without the risk of revealing the key to a 3rd party that may be trying to eavesdrop. It uses mathematical properties that allow both Bob and Alice to generate the same key without ever sending the key, so even if Trudy got all the messages deciding what key to use, she would not be able to generate the key.

For some context as to why this is important, say Bob wants to encrypt his messages but needs Alice to be able to decrypt them. So he picks the key 27 and sends it to Alice so she can decrypt his messages. If Trudy is listening to for messages between Bob and Alice when bob sends the key, then Trudy can decrypt everything Bob sends and even pretend to be bob by using his key and sending messages to Alice. So imagine this same situation if you were communication with a bank or other service. Trudy could not only see everything you are doing, she could take your password (that you encrypted to prove to the bank your identity) and rob you blind! With Diffie-Hellman the key is never sent between Bob and Alice, it is generated separately by both Bob and Alice in a way that Trudy can’t replicate even if she is eavesdropping.

How it Works:

I’ll walk you through the steps with Bob and Alice communicating while Trudy tries to eavesdrop. Bob and Alice start by agreeing upon 2 numbers P, a prime number, and G, the generator number.

Step 1:

In this example Bob and Alice decide P = 23, and G = 5.

Bob’s Info Alice’s Info Trudy’s Info P = 23 G = 5 P = 23 G = 5 P = 23 G = 5

Step 2:

Next Bob picks a random secret number Sbob, and Alice picks a random secret number Salice. Bob picks Sbob = 15, and Alice picks Salice = 6.

Bob’s Info Alice’s Info Trudy’s Info P = 23 G = 5 P = 23 G = 5 P = 23 G = 5 Sbob = 15 Salice = 6 Nothing

Step 3:

Bob and Alice both use their secret along with the function T = GS mod P then send them to each other. Bob generates Tbob = 515 mod 23 and finds TBob = 19, Bob then sends 19 to Alice. Alice does the same after finding Talice = 56 mod 23 = 2.

Bob’s Info Alice’s Info Trudy’s Info P = 23 G = 5 P = 23 G = 5 P = 23 G = 5 Sbob = 15 Salice = 6 Nothing Tbob = 19 Talice = 2 Talice = 2 Tbob = 19 Tbob = 19 Talice = 2

Step 4:

Bob and Alice now have all the information they need to generate the key they will use for encryption. They both use the function key = TS mod p. to get the key. Bob uses keybob = TaliceSbob mod P and gets keybob = 2. Alice uses keyalice = TbobSalice mod P and gets keyalice = 2.

Bob’s Info Alice’s Info Trudy’s Info P = 23 G = 5 P = 23 G = 5 P = 23 G = 5 Sbob = 15 Salice = 6 Nothing Tbob = 19 Talice = 2 Talice = 2 Tbob = 19 Tbob = 19 Talice = 2 Keybob = 2 Keyalice = 2 Nothing

Bob and Alice can now communicate using the key they generated and Trudy cannot generate the key without one of the secret integers that Bob or Alice picked, But since the secret numbers are never transmitted Trudy has no idea what they are. The only option would be for her to guess the key until she finds the right one, for this example this would happen very quickly but in practice this algorithm uses huge numbers. Numbers that would be very difficult to show an example with.

What makes this work:

This works because of how modulus and exponents work. Modulus makes sure you can’t simply find the secret value Bob or Alice used by working backwards. Use of exponents makes sure that both parties arrive at the same key.

Modulus:

Modulus if you don’t know is a mathematical operation that finds the remainder of a division. So, 5 mod 3 = 2 because the remainder of 5/3 is 2, 3 only goes into 5 once and the remaining value is 2. So in Diffie-Hellman if we had a P = 5 and calculate a T = 1 the secret could be 2 or 4 but there is now way to tell which. So if Trudy tried to generate the key she would not know what power to use on the T to get the key.

Exponents:

The main property of exponents used here is that (TSbob mod P)Salice is the same as (TSalice mod P)Sbob. Bob and Alice are essentially combining both their secrets numbers together without actually exchanging them.

Bringing it together:

The key remains a secret from Trudy because she needs either Bob’s or Alice’s secret number to generate the key. Trudy is unable to reverse engineer the secret number, and Bob and Alice apply their key to G before sending it to the other person to add their secret to G as well.

Diffie-Hellman Key Exchange. was originally published on Cole Talks

#computer science #cryptography #cyber security #diffie-hellman #network security #technology #coletalks

0 notes

coledeman · 8 years ago

Photo

Augmented Reality in 10 Lines of HTML

Tutorial from Alexandra Etienne is a guide to create a simple Augmented Reality project with a marker and web browser coding editor:

youtube

Do you want to do Augmented Reality on the web ? You can now do it in 10 lines of HTML! Seriously! Let me walk you thru the code, it’s crazy simple.

We released AR.js recently. You can experience efficient augmented reality for the web directly on your phone without installing any applications. But let’s go further and see how to produce your own augmented reality experience. The shortest example of AR.js is only 10lines of HTML thanks to the magic of a-frame. You can see it live on codepen

More Here

899 notes · View notes

coledeman · 8 years ago

Text

Cipher Application

For CSCI:4174 one of our assignment had a question where we had to implement 3 ciphers. The idea being learn how basic cryptography works before studying more complex algorithms that we use today. I first made the simple program with command line java. We just had to implement a Caesar cipher, Vigenère cipher, and a Matrix Transposition Cipher.

Caesar Cipher Encryption: The Caesar cipher was pretty straight forward, you just have to shift the letters. I transferred the letters to Unicode applies a key of value 0 to 26, then transferred them back.

public static String encryptCaesarCipher(String plainText, int key){ plainText = plainText.toLowerCase(); String result = ""; int tmp; for(int i = 0; i < plainText.length(); i++){ tmp = ((plainText.charAt(i)- 'a' + 1)+key)%26; if(tmp

Caesar Cipher Decryption: Decryption is basically the opposite, you just transfer the characters to Unicode again and just subtract the key.

public static String decryptCaesarCipher(String encryptedText, int key){ encryptedText = encryptedText.toLowerCase(); String result = ""; int tmp; for(int i = 0; i < encryptedText.length(); i++){ tmp = (encryptedText.charAt(i)- 'a' + 1); tmp = (tmp-key)%26; if(tmp

Vigenère Cipher:

Vigenère ciphers are a bit more complicated, for one instead of a number for the key you can use a word. Then they use a table, the key, and a cipher or plain text to decrypt or encrypt. The plain text is paired with a key and the letter in the intersection of each column and row matching each character pair is the cipher character.

By Brandon T. Fields (cdated) - Based upon Vigenere-square.png by en:User:Matt Crypto. This version created by bdesham in Inkscape, and modified by cdated to include visual guides.This vector image was created with Inkscape., Public Domain, https://commons.wikimedia.org/w/index.php?curid=15037524

For example let the plaintext be "ATTACKATDAWN" and the key be "LEMON". The first issue is the key isn't as long as the plaintext, so you repeat the key until it is. So you would get: Plaintext: ATTACKATDAWN and key: LEMONLEMONLE

So to get the cipher text you would pair the the key characters to rows and plaintext to columns or vise versa. So in the case the character at the intersection of row A and column L is L, the intersection of row T and column E is X, and so on. Once you go through all of the letters in this example you get the ciphertext "LXFOPVEFRNHR".

To get the plaintext back you do almost the same thing. You match the cipher text with the key the same way you do when encrypting with plain text. But when finding the plain text you go to the row of each character of the key and find where in that row the corresponding character from the ciphertext is in that row, then use the column letter for the plain text. For this example to find the first letter you would go to row L find L in that row, and see that it matches column A. Doing so would get you back to the message ATTACKATAWN". The implementation I made in java follows.

Vigenère Cipher Encrypt:

public static String encrypt(String plainText, String key) { plainText = plainText.toLowerCase(); String result = ""; String tmp = ""; int keyLength = key.length(); int num; for (int i = 0; i < plainText.length(); i++) { if(plainText.charAt(i) == ' '){ result+=' '; }else { num = ((plainText.charAt(i) - 'a') + (key.charAt(i % (keyLength)) - 'a')) % 26; if (num

Vigenère Cipher Decrypt:

public static String decrypt(String encryptedText, String key) { encryptedText = encryptedText.toLowerCase(); String result = ""; String tmp = ""; int keyLength = key.length(); for (int i = 0; i < encryptedText.length(); i++) { tmp += key.charAt(i % (keyLength)); } key = tmp; int num; for (int i = 0; i < encryptedText.length(); i++) { if (encryptedText.charAt(i) == ' ') { result += ' '; } else { num = ((encryptedText.charAt(i) - 'a') - (key.charAt(i) - 'a')) % 26; if (num <= -1) { num = 26 + num; } result += (char) (num + 'a'); } } return result; }</pre> Matrix Transposition Cipher: The matrix transposition cipher surprisingly enough uses a matrix. You start with your plain text and decide how long you want your key to be, let L = key length, then start filling in a matrix with L columns left to right with your plain text, replacing spaces with '%'. For my example I'll go with a key = { 3, 1, 5, 2, 4}, a length of 5, and a plain text of "this is a secret message". The filled matrix would look like this:

The key is a list of numbers corresponding to the columns. You then reform the matrix by row as described by the key. With the key = { 3, 1, 5, 2, 4} the matrix would look like this:

You then get the cipher text by reading left to right again, int his case the cipher text would be "iT%hs%i%sacseermts%egs%ae". To dcrypt it you just follow the steps backwards. Put the cipher text back into a matrix left to right. Rearrange the columns 1 to 5 using the key as a map then read it left to right to get the original message.

I implemented it in java like this:

public static String encrypt(String plainText, int[] key) { if(!checkValidKey(key)) return "key is invalid."; plainText = plainText.toLowerCase(); String result = ""; double temp = (double)plainText.length()/((double)key.length); int x = key.length; int y = (int) Math.ceil(temp); int rowColumn = y*x; //System.out.println("x length: "+x+"\ny Length: "+y+"\nText Length: "+plainText.length()); char[][] matrix = new char[x][y]; plainText = plainText.replace(' ', '%'); int count = 0; for (int j = 0; j < y; j++){ for (int i = 0; i < x; i++){ if(count < plainText.length()) { matrix[i][j] = plainText.charAt(count); count++; }else{ matrix[i][j] = '%'; } } } for (int i = 0; i < x; i++){ for (int j = 0; j < y; j++){ result += matrix[key[i]-1][j]; } } return result; } public static String decrypt(String encryptedText, int[] key) { if(!checkValidKey(key)) return "key is invalid."; encryptedText = encryptedText.toLowerCase(); String result = ""; double temp = (double)encryptedText.length()/((double)key.length); int x = key.length; int y = (int) Math.ceil(temp); int rowColumn = y*x; //System.out.println("x length: "+x+"\ny Length: "+y+"\nText Length: "+encryptedText.length()); char[][] matrix = new char[x][y]; int count = 0; for (int i = 0; i < x; i++){ for (int j = 0; j < y; j++){ if(count < encryptedText.length()) { matrix[key[i]-1][j] = encryptedText.charAt(count); count++; } } } for (int j = 0; j < y; j++){ for (int i = 0; i < x; i++){ result += matrix[i][j]; } } return result; } public static int[] stringToKey(String key){ int k[] = new int[key.length()]; for(int i = 0; i

Then I rebuilt this all in javascript and built a webapp you can find here. Cipher Application was originally published on Cole Talks

#caesar cipher #ciphers #cryptography #java #javascript #matrix transposition cipher #vigenere cipher #coletalks

0 notes