Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sun, Oct 17, 2004 at 08:52:32AM -0400, Jerry Feldman wrote: > > There is a protocol called ASN.1 (http://asn1.elibel.tm.fr/en/) that is > used in some places. Essentially, everything is encoded into a TLD > (type-length-data) scheme where every data type is encoded as a byte > (eg. 32 bit int might be 1, char string (eg. octet) might be 2, user > defined 4, ...). The length is usually encoded in 7 bits. If the length > is longer than 127, then the length byte becomes a negative length of > the length. Example, sending a packet containing a string "abc", and int > 123: > 40X0A23abc13123 > The 0x0A is the length of the packet Argh! Bad ASN.1 parsers have been responsible for zillions of security holes in the last few years. When designing a protocol, please keep in mind the following concepts: - first, if at all feasible, use an existing protocol. Best of all a widely-known standard. - second, if possible, extend an existing protocol. Make sure you increment the version number or otherwise indicate your incompatibilities with the original. - third, design your protocol to look like a proven existing standard protocol. Keep it as simple as possible. - fourth, make sure it is at least human readable and writable for the simpler exchanges. This will be of enormous help in debugging. - fifth, if you can't do any of the above, at least document the protocol so rigorously that any half-competent beginning programmer can write a working client. If you don't know BNF, learn it. -dsr- tired of gratuitously incompatible protocols
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |