[Erik de Jong <erikdejong@xxxxxxxxx>]

On Mon, Feb 13, 2017 at 9:46 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:

On Mon, Feb 13, 2017 at 07:31:50PM +0100, Erik de Jong wrote:
> On Sun, Feb 12, 2017 at 3:38 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
>
> > On Sun, Feb 12, 2017 at 02:40:03PM +0100, Pascal Quantin wrote:
> > > Le 12 févr. 2017 11:12, "Erik de Jong" <erikdejong@xxxxxxxxx> a écrit :
> > > On Sat, Feb 11, 2017 at 10:38 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> > > > (forgot to attach the file lists...)
> > >
> > > I'll get to work on the aes_cmac_encrypt_* and crypt_* symbols. Will you
> > > make a separate change for this on which we'll both work or is it
> > > additional work on 20030?
> >
> > You can create a separate change, 20030 is focussed on making Libgcrypt
> > mandatory but will not rewrite other parts (in order to make review
> > easier).
> >
>
> Alright! I've removed the md4 and rc4 symbols. Don't feel confident enough
> to remove the crypt_des_ecb calls because I'm not sure what is happening
> exactly, so I'm worried it'll break.

Ehh, that indeed needs a closer look. I'll take a look once you finished
the patch (to avoid possible conflicts within the file).

> Looks like wsutil/aes.h is also used by epan/dissectors/packet-dof.c and
> epan/crypt/airpdcap_ccmp.c for rijndael_encrypt(), so we ought to put those
> on the list as well.

Oh right! I grepped for the cipher names based on the filename and
missed Rijndael.

General remark, when rewriting files, can you try to find a pcap and
confirm that the before/after result is the same? You can then add this
to the commit message.

I did not find any captures that are appropriate for the rc4 related calls, looks like the captures up on the web are about other (AES) encryption. Removed the Rijndael references in the epan/crypt/* but looks like the information for the sample capture for the DOF protocol (https://wiki.wireshark.org/SampleCaptures#DOF_.28Distributed_Object_Framework.29_Protocols) either has the wrong decryption info or the decryption is already broken as it doesn't decrypt in Fedora's stock Wireshark (2.2), so that'll be difficult to verify.

 

--
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe