I've understood that an USSD message consists of 160 bytes. For 7 bit data coding schemes, the maximum number of characters is 160*8/7 which gives 182 characters. It's unclear to me what is the maximum number of characters for UCS2 encoding. Normally, it would be something like 160/2, but I have some mixed information on this.
The maximum size of a USSD message is 160 bytes. For GSM 7 Bit messages you are correct in saying the limit is 182 characters. UC2 encoding per definition is fixed 2 bytes per character so you will have a maximum of 80 characters.
Related
I'm reading on this topic, and I just found that IP headers, or even TCP headers, can be of variable length.
I thought routers will use a known length, divided into segments of a known format, to do whatever they do. So, how can you know which segements of bits mean what, if the length of the header is variable?
The way I understand it, is that the Options field at the end of the header determines the total length of the header (present if the Length field value > 5). The Length field has a minimum value of 5 (no options present) and a maximum of 15. This indicates a header length from 20 bytes (5 × 32 bits) to 60 bytes (15 × 32 bits). As all other fields apart from the Options field have a fixed length, it is clear where the header ends and where a given field is supposed to be. The Option field in itself also includes a Option length field for determining the length of Option data.
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.
two host A and B are communicating with each other using TCP. Assume that the sequence number field starts at 0 and the receiver employs cummulative ACK. A has successfully send 465 bytes of data which were also acked by B. Suppose A were now to send 3 segment of size 110, 40, 60 size. what sequence number will the third segment carry ??
This is very simple to work out, and it sounds a lot like a homework problem. I usually won't answer these, but...
Remember that the initial SYN consumes 1 byte in the connection. This means that the initial SYN with sequence number zero is ACKed as 1.
We now transfer 465 bytes. This means that the last sequence number ACKed will be 466, and 466 will now appear as the sequence number from A to B.
We now send 110 bytes. The sequence number in the packet will be 466 with a data payload of 110. The ACK will be for 576.
Following this, 40 more bytes are sent. This will have a sequence number of 576 in the packet with 40 bytes of payload and the ACK will be for 616.
That brings us to the last segment. The sequence number in the segment should be 616, as long as I've done the maths correctly in my head, and this is the sequence number in the packet that you are asking about. The ACK for that will be for 676.
I have this piece of decoded message, it's a homework but i can't solve it, the message is
IZWGCZZ2EBAUWRSVOJAU45DSOVCEOZKS
N5CHKQLSM5GGSQ2VNVIECUSEIU======
there is a hint saying The string is encoded using an unusual number base. The numbers 2 - 7 are represented and the letters A - Z are represented.
i have looked into the internet but i couldn't find anything, please if anyone could help understand this problem and solve it i would appreciate it
Let's see: A-Z + 2-7 = 32 possible values.
32 values can be contained in 5 bits, thus each byte of the message represents 5 bits.
To decode, each of those 5 bits have to be put together in one long bit-string which is then read as an 8 bit ASCII string.
Or, in other words: Base32 encoding.
So:
IZWGCZZ2EBAUWRSVOJAU45DSOVCEOZKSN5CHKQLSM5GGSQ2VNVIECUSEIU======
converts to:
Flag: AKFUrANtruDGeRoDuArgLiCUmPARDE
See here to test the decoding.
I created a file that contains 100,000 numbers that were drawn uniformly (with probability 1/8) from the set {1,2,3,4,5,6,7,8}.
When a look at the size of this file on my hard-disk it is 293 KB (kilo-byte) which makes sense because one needs 3 bits to "identify" a number between 1 and 8 and 3*100,000 = 300 KB.
Next I compress the file using Win-zip and find that the file is reduced to only 57 KB ! How can this be since I expect that the random-number generator I used for my draws is - for all practical purposes - ideal. This means that the sequence should be truly random and the size of the file should therefore be given by its entropy ( which is 300 KB)?
I am afraid you are confused about certain concepts.
3 bits times 100,000 gives you 300,000 bits, and there are 8 bits to the byte, which corresponds to roughly 37.5 KB. That's a far cry from 300 KB.
(And in any case, if you were to create "a file that contains 100,000 numbers", there is no magic fairy sitting on your hard disk, who will figure out the min & max range of your numbers, and store them in the file using the smallest number of bits necessary to represent them all.)
So, it is very important to get it out of the way that 300 KB has absolutely nothing to do with the entropy of 100,000 single-digit numbers.
You told us absolutely nothing about how you created that file, so its file format is a mystery, but we can make some simple calculations and guesses: 293 KB times 1024 is 300,000, so what you have is a 300,000 byte file. Which means that you are writing 3 bytes per number. Which means that you have written these numbers as text, in a text file, either each digit followed by a comma, then followed by a space, or each digit followed by a carriage return and a linefeed, or something similar.
Text file formats are extremely wasteful in terms of storage space.
So, yes, this is a highly compressible file consisting mostly of identical bytes, and even the bytes that are not identical (the digits) all map to just 3 bits each, so it is no wonder that the entire file gets compressed so well.
No laws of nature were harmed during the making of this question.