I want to create an encryption program for studies using the DES algorithm. If my data is more than 64 bytes I can use CBC or EBC mode to encrypt it. But what if my data file is less than 64 bytes? Should I add white spaces at the end of the file to fill it and get 64 bytes? What is a good approach?
The DES block size is 64 bits, or 8 bytes. If your message is less than 8 bytes, you need to pad it. A common scheme is to fill out the block by repeatedly appending the length of the padding. For example, if your message is 3 bytes, and you need to fill an 8-byte block, you need 5 bytes of padding. Append the value 5, 5 times, to the message:
// Message ABC + 5 bytes of padding
0x41 0x42 0x43 + 0x05 0x05 0x05 0x05 0x05
This implies you need at least one byte of padding, so if your message is a complete block, you need to add a whole extra block just for padding. To remove the padding, look at the value of the last byte, N, and verify that the last N bytes of the plain text have that same value.
Related
I'm just starting to learn assembly language, and we are working with hex addresses. Below is a question of ours. I'm not sure how it adds up though. I know the answer is 0x202C, but how did we get there? Can you help explain the processes step by step, in the most basic way possible to help me understand? Thank you!!
The following data segment starts at memory address 0x2000 (hexadecimal)
.data
printString BYTE "Assembly is fun",0
moreBytes BYTE 24 DUP(0)
dateIssued DWORD ?
dueDate DWORD ?
What is the hexadecimal address of dueDate?
You have three data definitions to add together:
printString is an ASCII text followed by a zero byte. The string part is 15 bytes long, and with the terminal zero byte that makes 16. So the offset of the next data item is 0x2010 (16 decimal is 0x10 hex). printString starts at 0x2000, and the next one starts after the last byte of printString, so you have to add its length to its offset to get to the next offset.
moreBytes is 24 bytes long, because that's how DUP works. BYTE x DUP (y) means "X bytes of value Y". So the offset of the next data item is 0x2028, as 24 decimal is 0x18 hex.
dateIssued is 4 bytes long, because that's the definition of a DWORD. So the next one is at 0x0x2C, since 8+4=12, and that's 0xC in hex notation.
Alternatively, you could add the three lenghts together, getting 44. 44 in hex would be 0x2C.
The first example of Section 5.7 of Websocket Protocol RFC 6455 reads:
A single-frame unmasked text message
0x81 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello")
What are the first two octets in this example and why are they there?
Looking up the UTF-8 codes for the last five octets I can see how those bytes would translate to Hello.
The first two octets in this example contain metadata about the data frame and the payload it contains. The last five octets represent the payload or Hello.
The first two octets 0x81 0x05 are hexadecimal representations of two bytes or 16 bits of data. In binary they translate to: 1000 0001 0000 0101.
Using the Data Frame Diagram from the RFC you can see what these bits tell us about the data frame. To summarize:
1st bit (FIN): indicates this is the final fragment of the message being sent
5th-8th bits (opcode): the payload is a text message in UTF-8
9th-16th bits (payload length): the length of the payload is 5
I have a data that needs to be stored in a database as encrypted, the maximum length of the data before encryption is 50 chars (English or Arabic), I need to encrypt the data using AES-128 bit, and store the output in the database (base64string).
How to know the length of the data after encryption?
Try it with your specified algorithm, block size, IV size, and see what size output you get :-)
First it depends on the encoding of the input text. Is it UTF8? UTF16?
Lets assume UTF8 so 1 Byte per character means 50 Bytes of input data to your encryption algorithm. (100 Bytes if UTF16)
Then you will pad to the Block Size for the algorithm. AES, regardless of key size is a block of 16 Bytes. So we will be padded out to 64 Bytes (Or 112 for UTF 16)
Then we need to store the IV and header information. So that is (usually, with default settings/IV sizes) another 16Bytes so we are at 80 Bytes (Or 128 for UTF16)
Finally we are encoding to Base64. I assume you want string length, since otherwise it is wasteful to make it into a string. So Base 64 bloats the string using the following formula: Ceil(bytes/3) * 4. So for us that is Ceil(80/3) = 27 * 4 = 108 characters (Or 172 for UTF 16)
Again this is all highly dependent on your choices of how you encrypt, what the text is encoded as, etc.
I would try it with your scenario before relying on these numbers for anything useful.
I've written a segmenter and have just added AES encryption, but I'm a little puzzled by the PKCS7 padding. When playing on the iPad, I get glitches every 12 seconds, which is my segment length.
If my file is 4 bytes short of being on a 16 byte boundary, I add 0x04 x 4.
If it's 8 bytes short I add 0x08 x 8.
If it's 12 bytes short I add 0x0c x 12.
I then encrypt the package using the multiple of 16 size, is this correct?
Next question is, do I send the full encoded packet, so it's a multiple of 16, or do I send the real length (before padding)?
I downloaded Hex Workshop, and I was told to read a .dbc file.
It should contain 28,315 if you read
offset 0x04 and 0x05
I am unsure how to do this? What does 0x04 mean?
0x04 is hex for 4 (the 0x is just a common prefix convention for base 16 representation of numbers - since many people think in decimal), and that would be the fourth byte (since they are saying offset, they probably count the first byte as byte 0, so offset 0x04 would be the 5th byte).
I guess they are saying that the 4th and 5th byte together would be 28315, but did they say if this is little-endian or big-endian?
28315 (decimal) is 0x6E9B in hexadecimal notation, probably in the file in order 0x9B 0x6E if it's little-endian.
Note: Little-endian and big-endian refer to the order bytes are written. Humans typical write decimal notation and hexadecimal in a big-endian way, so:
256 would be written as 0x0100 (digits on the left are the biggest scale)
But that takes two bytes and little-endian systems will write the low byte first: 0x00 0x01. Big-endian systems will write the high-byte first: 0x01 0x00.
Typically Intel systems are little-endian and other systems vary.
Think of a binary file as a linear array of bytes.
0x04 would be the 5th (in a 0 based array) element in the array, and 0x05 would be the 6th.
The two values in 0x04 and 0x05 can be OR'ed together to create the number 28,315.
Since the value you are reading is 16 bit, you need to bitshift one value over and then OR them together, ie if you were manipulating the file in c#, you would use something like this:
int value = (ByteArray[4] >> 8) | ByteArray[5]);
Hopefully this helps explain how hex addresses work.
It's the 4th and the 5th XX code your viewing...
1 2 3 4 5 6
01 AB 11 7B FF 5A
So, the 0x04 and 0x05 is "7B" and "FF".
Assuming what you're saying, in your case 7BFF should be equal to your desired value.
HTH
0x04 in hex is 4 in decimal. 0x10 in hex is 16 in decimal. calc.exe can convert between hex and decimal for you.
Offset 4 means 4 bytes from the start of the file. Offset 0 is the first byte in the file.
Look at bytes 4 and five they should have the values 0x6E 0x9B (or 0x9B 0x6E) depending on your endianess.
Start here. Once you learn how to read hexadecimal values, you'll be in much better shape to actually solve your problem.