ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol diss

From: Sake Blok <sake@xxxxxxxxxx>
Date: Tue, 30 Sep 2008 10:43:22 +0200
On Thu, Aug 07, 2008 at 03:57:46PM +0200, Luis EG Ontanon wrote:
> My vote goes for 2) :
> 
> Wireshark is a troubleshooting tool and a vulnerable key can be source
> of trouble. It would be plainly wrong not to notify of a potential
> source of trouble if we can.
> 
> I wonder whether we actually need to decrypt? I think we just need to
> build a hash of broken keypairs indexed by PubKeys and check the
> PubKey during the setup exchange, if the key is one of the well-known
> 64k we just mark it.
> 
> It would be also interesting to check for CA certs whose PrivKey is
> one of the well known 64k. Is that feasable?

OK, it's been a while, but no decission has been made for enhancing
Wireshark with Weak-Key detection and decryption.

I re-read all the mails in this discussion and it can be summarized as
follows:

- Most of us like the functionality of detecting weak keys

- Most of us dislike the cpu-load it would take, so there should
  be a preference for it which default to "disable".

- Most of us dislike the idea that WS can be used as a cracking
  tool, so there should only be detection of the weak key and as
  little as possible information to the user on how to decrypt
  the traffic.

Is this something we can all (oh well, most of us) agree on? 

If so, I think the option of using hashes of the weak keys instead of
the keys themselves will address both the performance as the security
issue.

Cheers,


Sake