Calculation of number of bytes submitted with form
 

Setting up a web site for a Not-For-Profit, some forms used, I wish to be able to estimate what will be the size of the data sent to me (downloaded to my computer) with these forms.

Form one format will be 3 fields of 5 characters (xx=12&yy=34&zz=56) total 17 'useful' bytes returned.

Form two format will be 1 field of 5 characters (aa=78) total 5 'useful' bytes returned.

Form three will be 6 fields of variable length (max 64 bytes in total)

Form one and two are not encrypted but form three is encrypted.

I'd like to use symmetric encryption for form three because it seems from what I understand I might be able to convert a number of fields of various length to an encrypted result of constant length.

Can anyone suggest a method of calculation? Or a suitable tutorial to visit?

What I do not know:
1) Are details of forms (like clients variables) sent compressed or plain text or coded (?
2) Overhead to establish non-secured connection
3) Secure connection is required between form two and three, what is the overhead (number of bytes) required to establish connection?
4) What size would be an encrypted 64 bytes of data using 40 or 56 or
128 bits symmetric encryption?
5)How to put it all together as far as HTML goes.

Any help most appreciated.

blampain

Didn't you just do an estimate yourself of how much data would be sent?

As for the encryption part. I guess that your referring to a hash algorith like MD5.
A hash algorith are strictly one-way and cannot be reversed. That means that you can't encrypt data and then later get that information back again.

Thanks to ugge.

If I expect 17 bytes sent from a form, the packets sent to my computer
amount to a much larger set of data including environment variables from the client's computer, client's address etc and this is what i'd like to figure out, is it plain text, encoded, compressed or whatever, or have I got the wrong idea of the protocol? This is to try to guess bandwidth usage.

I know a hash is a one way encryption, but it seem symmetric encryption is not all hashes.

From what I've read, it looks common to encrypt a document of variable length (max 64 bytes) into an encrypted document of fixed length (which is not a hash) and decode it at the other end.

The reason for my question is to try and write to disk the encoded data and decode it later if need be. For example if a new member sends to me some details like name and address, this will be over a secure connection (encrypted) and if the length of this document is fixed, it makes it very easy to save to disk and safer if it is encrypted. This would also be a lot more efficient than decoding the encryption, then saving the result to disk, then encrypting the whole drive.

However if the encrypted document consists of 2k of hexadecimal then my idea is not feasible.

Also if the encrypted document representing 64 bytes is 2k of hexadecimal,
I have to base bandwidth calculations on 2k of data received, not 64 bytes.

Hope this makes sense for the gurus.

Ok.
The easiest way to estimate your bandwidth usage is to actually send a couple of forms and then capture them using a packet monitor like ethereal or equal program.

The encryption usually used for web traffic is SSL which is transparent to the client as well as the server when set up. That mean your server will get all decrypted data. The SSL is a combination of a public key encryption and a symmetric encryption. The key used for the symmetric part is a session key.

What language are you planing to use for your web page? php/perl?
When programming web pages you usually get access at the application layer of the network traffic, all other steps are performed by the NIC, server and TCP/IP stack.
To be able to save the actual network traffic you will probably have to use a packet monitor, but this is not a good solution to the problem. You would have trouble filtering out the relevant packets and even if you made it you would have trouble to make sense out of the data due to the encryption.

Thanks again ugge. It looks like I'll have to drop the idea of saving the encrypted data.

I find it a lot easier to write my CGIs in assembly, I don't know PHP or Perl or C and wish to have nothing to do with them unless absolutely necessary. If absolutely necessary I would consider C, I think encryption
is enough load already on my processor.

Thanks for the tip about packets inspection, which I will follow. Any comment about CGI in assembly will be a bonus really.

It would probably be a speed bonus, but since it takes more time writing assembly code the benefit sometimes cancel each other.
Also the assembly code is very closely connected to your hardware.
There must be some reason why almost everyone uses high level programming languages.

What kind of hardware are you running that canät cope with these languages?

If you would consider using some other language then I would suggest php since it is very easy to learn, and very powerfull.

Launching the Not-For-Profit is anticipated about end of 2004 early 2005.
The purchase of the hardware is left for as late as possible due to fast changes in hardwares and continuing falling prices. It's anticipated we'll start with a powerful PC, SATA and RAID 1 and switch to more powerful
computers as soon as necessary.

Current set up is one Celeron 1100 running WinXP which is required because of my Satellite connection but which I am looking forward to wipe off within weeks when I move to ADSL territory and one Athlon 2000 running Redhat 9 and one old Pentium 133 to make sure pages render
reliably.

As you said, speed is the main advantage of assembly, the second advantage is compactness and what I particularly like is that no external
libraries are required. Some years of work have been spent on this, a little more for assembly is OK. Portability doesn't look that important, in fact we
may have to restrict it for safety reasons.