The Agent Based Crypto Protocol The ABC-Protocol by Jordan Hind MSE Presentation 3

Agenda ● Introduction ● The Good News ● Component Design ● Development Notes ● What’s Missing? ● The Bug Epidemic of 2006  The Conflicting requirements (non-software bug)  The Serpent Bug (software bug) ● Testing ● The code reviews. ● Thanks! ● Demo

Introduction ● The ABC protocol was an application protocol to deliver highly secure data connections while fulfilling a few requirements that are specific to agents.

The Good News ● Its done and it works well! ● All requirements in the Vision document were fully met. ● All the required documents are on the abcprotocol.org website, with a few extra things.

Component Design ● The final design was very close to the planned design. ● 2 UML models ● One is in the component design document, its from the updated/redone USE/OCL. ● The other is on the website and is auto generated from Rational Rose (shown in the next slide)

Rational Generated UML

Development Notes ● I went to great efforts to avoid using dynamic memory in this implementation. This includes obvious things like malloc as well as less obvious things like how the objects are instantiated. It is my understanding that the only part of the project to take place in the heap is the dynamically loaded DLL used in the Windows implementation. ● At this time, I don’t believe there are any remote arbitrary code exploits in the library. All data is handled based on hard limits with no user defined limits.

Development Notes Cont. ● The problem I encountered with using Curve25519 on a Windows XP sp2 machine is that its written in assembly that should be compiled with gcc and my code is C++ that needs to be compiled with g++ version ● I tried EVERYTHING, and the only thing I got to work was to create another DLL using C code and the Curve25519 assembly. Dynamically load this DLL at runtime into the ABCP DLL and call the needed ECC functions.

Whats Missing? ● In the Design document I stated that I would like to have AES AND Serpent cryptographic ciphers. ● After working with them, I found that the Serpent was all I needed. ● It isn't as slow as I was told (see testing results), and the NIST Rijndael isn't public domain. ● Oh, and a web page on my experience with provably secure protocols. Every time I started writing one, I could only come up with “Its a good idea, but the tools are immature.”

Bring on the Bug! ● Bug 0, the conflicting requirements. ● In the vision document I stated that packet size should be variable. This is a bad requirement for an application level protocol, TCP will give you an optimal packet size. The actual Design was built around this requirement. ● In the design document I stated that EAX mode would be use. EAX mode is tightly coupled to ACTUAL packet size by including a hash of the packet. I did NOT correctly build this into the design. ● In the end, I found a compromise that would work... interpret “packet” size as “transmission” size, follow the original design and made a slight modification to EAX.

The Software Bug! ● The Serpent key initialization function expects a bad key, then builds a good one from the key its given. ● Not fully understanding this, I sent my “strong” key through the function. ● This seg-faulted occasionally when tested in bulk runs, but worked in the debugger every time. ● This was the bug that prevented me from presenting on time. ● Fixed New Years morning 2007 at 2AM.

Testing ● Added to the phase 2 testing document now located in the Updates section of Phase3. ● Added another test group that tests the protocol decisions (out of sync packets, invalid packets, etc).

Testing, Pleasantly surprising! ● All test passed (after some debugging on a few of them). ● Head to head against SSH/SCP the DLL did much better than expected. ● K files  SSH/SCP.83 seconds each  ABCP.038 seconds each ● kbyte files  SSH/SCP.82 second each  ABCP.039 seconds each ● MB file  SSH/SCP 1 second  ABCP 2 seconds ● 16 – 1.5 MB files  SSH/SCP seconds each  ABCP seconds each ● But Wait...

Testing Flaw? ● A few days after those tests, I realized that I had left the ABCP test code (not the DLL) in an unoptimized state, only sending a smaller amount of data than the set transmission size. ● When the overhead was removed. ● MB files  SSH/SCP 20 seconds  ABCP 20 seconds ● Its competitive again.

Code Reviews ● I asked two Senior developers to review my project and give me their feedback.  Dr. Steve Brooks  Tim Freund ● Both of them really put a lot into it, giving me a great amount of feedback. ● Both positive and negative.

Lessons Learned ● Provable security might exist! ● I learned a TON about cryptography. ● I learned the difficulty of debugging an application with multiple random fields. ● Most importantly, I learned whats involved in implementing a complex topic you are NOT an expert on.

Time Spent (Minus some of Dec +.5 of Jan) ●

Before I forget, Thanks! ● Without this project I wouldn't have been able to study cryptography and provable security very much in my graduate education.

Demo ●