Fix misspelling in comment
Prevent buffer overflow from untrusted RTP/SRTP lengths

When computing the start address of the RTP data to encrypt or SRTP
data to decrypt (`enc_start`), we are using `hdr->cc` (the CSRC
count), which is untrusted data from the packet, and the length field
of an RTP header extension, which is also untrusted and unchecked data
from the packet.

This value then pollutes our calculation of how much data we'll be
encrypting or decrypting (`enc_octet_len`), possibly causing us to
underflow.

We'll then call `cipher_encrypt()` or `cipher_decrypt()` with these
two values, causing us to read from and write to arbitrary addresses
in memory.

(In the AEAD functions, we'd also pollute `aad_len`, which would cause
us to read undefined memory in `cipher_set_aad`.)

This commit adds checks to verify that the `enc_start` we calculate is
sane based on the actual packet length.
Avoid buffer over-read on null cipher AEAD

In the defined AEAD modes, SRTP packets must always be encrypted and
authenticated, but SRTCP packets may be only authenticated.  It's
possible, therefore, for us to end up in `srtp_protect_aead()` without
the `sec_serv_conf` bit being set.  We should just ignore this and
encrypt the RTP packet anyway.

What we are doing instead is encrypting the packet anyway, but setting
`enc_start` to NULL first.  This causes `aad_len` to underflow which
will cause us to over-read in `cipher_set_aad()`.

If we could get past that, we would try to read and write memory
starting at 0x0 down in `cipher_encrypt()`.

This commit causes us to not check the `sec_serv_conf` bit and never
set `enc_start` to NULL in `srtp_protect_aead()`.

`srtp_unprotect_aead()` does not contain a similar error.
Avoid buffer-overflow on short RTCP/SRTCP packets

In `srtp_unprotect_rtcp()` we are not validating that the packet
length is as long as the minimum required.  This would cause
`enc_octet_len` to underflow, which would cause us to try to decrypt
data past the end of the packet in memory -- a buffer over-read and
buffer overflow.

In `srtp_protect_rtcp()`, we were similarly not validating the packet
length.  Here we were also polluting the address of the SRTCP
encrypted flag and index (the `trailer`), causing us to write one word
to a bogus memory address before getting to the encryption where we
would also overflow.

In this commit we add checks to appropriately validate the RTCP/SRTCP
packet lengths.

`srtp_unprotect_rtcp_aead()` (but not protect) did correctly validate
the packet length; this check would now be redundant as the check in
`srtcp_unprotect_rtcp()` will also run first, so it has been removed.
Use AES ICM state counter to determine when to reinitialize the prng.
Merge pull request #53 from traviscross/master

Reviewed the code and it looks good.  Thanks for the contribution.
Fix calculation of RTP/SRTP packet end address

Our validation of `enc_start` was subtly wrong; we were adding a length
in octets as a length in 4 byte words.  This would allow underflow of
`enc_octet_len`.  This commit corrects the calculation.

Relates-to: fe367616718862a228f5859b83c383593dd4b79d
Fix cast to include entire expression

Elsewhere in the code this calculation casts the entire result to an
unsigned int.  Here we were just casting the octet length of the packet
before doing the subtraction, which has different semantics.  Casting
the entire expression seems more reasonable.
Simplify calculation of encrypted octet length

We were calculating the `enc_octet_len` value by computing an offset
in 4-byte words, then left shifting by 2 so we could subtract from a
length in octets.  This was a bit opaque.  We'll let the compiler do
this work instead by computing the offset in octets.
Add missing `char` to declaration

The bit-fields of these structs are defined as unsigned chars
apparently to appease Microsoft's compiler.  One field in the struct
for big-endian systems was missing this declaration.
Say `unsigned int` rather than `unsigned`

`unsigned int` == `unsigned` in C, but we were using both forms.  This
commit standardizes us to using `unsigned int`.
Validate passed in signed length value

In other functions we check right away that the `pkt_octet_len` is
greater than zero, but in `srtp_unprotect_rtcp` we were waiting until
we knew the tag length, at which point we had already used the value.
We'll do an initial check here to make sure the value is sane.
Use `unsigned int` internally for `pkt_octet_len`

Now that we always validate that the passed in length is positive, we
can treat the value as unsigned deeper in our code.
Avoid compiler warning about uninitialized value

The `verbose` value here will never be used uninitialized because the
branches in which it would not be set lead us to call exit().  But
gcc-4.8 currently can't see that.
Merge pull request #55 from traviscross/master

Thanks for the contribution.  I am seeing one compiler warning with this commit.  I'll fix it after the merge.
Moved packet length sanity check until after we've derived the expected tag length based on the session context.  This resolves the compiler warning due to tag_len being used uninitialized.
Merge pull request #54 from richrod/ctr_prng_exhaustion

Thanks for the contribution.
Validate passed in signed length value (again)

In other functions we check right away that the `pkt_octet_len` is
greater than zero, but in `srtp_unprotect_rtcp` we were waiting until
we knew the tag length, at which point we had already used the value.
We'll do an initial check here to make sure the value is sane.

We tried adding this check back in commit
444a544c0c525c1fe6ccc560ae2ddcf38e6a461c, but that commit erroneously
used the tag length in the calculation.  The comment above it made it
clear that was unintended.

This check must come before we compute the tag length or we'll have
cast the `*pkt_octet_length` to an unsigned value in the call to
`srtp_stream_init_from_ekt()` without first checking that the value is
greater than zero.

This reverts the non-whitespace changes in commit
73e3093fcc309328aeb1201373e30ade6137b9f2.
Merge pull request #57 from traviscross/master

Thanks for the contribution.
Minor changes to autoconf and Makefile to resolve issues #59 and #60.