date:20060907

[Wireshark-dev] ESP Patch for Hexadecimal keys

2006-09-07 Thread Frédéric Roudaut



Hi,

as requested  here is a patch  in order to take into account  Encryption 
and Authentication keys for ESP in hexa. 
You only have to write your key with 0x first. In this case if the key 
is not in 8-bit unit, it will be considered as starting with a "0" (4 bits).
Excepted this case, the key should be completely written, even if it 
starts with "0x00".


Nevertheless, if the box contains a key with white spaces before "0x",  
it will be taken into account. Ie if the ESP preference contains  
"0xff",  it will not be considered  as an hexadecimal key (4 
white spaces before 0x). I do not think it is a problem but please tell 
me if it is, I will correct this.


Moreover I noticed an editorial issue in the Author files ;-). IPsec 
should be written like this and not IP-sec.

could you please update this ?

best regards,

ps : in attachment, you will also get some examples for using 
Hexadecimal keys (preference and capture files, IPsec policy for setkey).

ps2 : sorry for the off-by-one errors ;-(

---
Frederic Roudaut



Filonenko Alexander-AAF013 wrote:

Frederic,
 
Thank you for the response. While adding this feature, do you plan to 
add another checkbox in the ESP preferences so the user can switch 
between ASCII/hex modes for encryption keys?
 
Thank you,

Alex Filonenko
 
 



*From:* Frédéric Roudaut [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, August 01, 2006 5:19 AM
*To:* Filonenko Alexander-AAF013
*Cc:* Ethereal development; Developer support list for Wireshark
*Subject:* Re: IPsec Dissector to decrypt ESP Payload

Hi,

sorry for my late answer. You're right for the key. To enter binary 
keys you need to modify the dissector. It should easy to adapt. If 
needed, I could easily add this but however not before the beginning 
of september.

Sorry for that.

best regards,

--
Frederic Roudaut


Filonenko Alexander-AAF013 a écrit :

Frederic,

I am using ESP decryption features of your dissector and it is very useful. 
I have one question though. How can I use arbitrary (non-ASCII) encryption key with preferences available for ESP? Is the key limited to ASCII characters only? 


Thank you,
Alex

-Original Message-
From: Filonenko Alexander-AAF013 
Sent: Friday, February 24, 2006 4:43 PM

To: 'Ethereal development'
Subject: RE: [Ethereal-dev] IPsec Dissector to decrypt ESP Payload

Frederic,

I find IPsec functionality you have added to the dissector very useful.
Hope I can provide you with some feedback in a few weeks.

Thank you,
Alex Filonenko 

  

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Frederic 
Roudaut

Sent: Friday, February 24, 2006 10:01 AM
To: Ethereal development
Subject: [Ethereal-dev] IPsec Dissector to decrypt ESP Payload


Hi,

finally, I have updated my dissector using libgcrypt.
It does not use openssl anymore.
If gnutls is installed, all should work.
Thus, now it should decrypt and dissect (transport/tunnel/several 
encapsulations ...) :


- NULL Encryption Algorithm
- TripleDES-CBC [RFC2451] : keylen 192 bits.
- AES-CBC with 128-bit keys [RFC3602] : keylen 128 and 192/256 bits.
- AES-CTR [RFC3686] : keylen 160/224/288 bits. The remaining
32 bits will be used as nonce.
- DES-CBC [RFC2405] : keylen 64 bits

I also have added :

- BLOWFISH-CBC : keylen 128 bits.
- TWOFISH-CBC : keylen 128/256 bits.

You have to indicate the Authentication algorithm even if all 
Algorithms since it uses 12 bytes in the Auth field should work (have 
a look to the README to understand why I put it

;-) ). If you consider I have to throw it away please tell me.

HMAC-SHA1-96 [RFC2404]
NULL
AES-XCBC-MAC-96 [RFC3566]
HMAC-MD5-96 [RFC2403]

In the attachment you will get :
- this dissector
- a new README
- some example capture files with associated preferences files (and 
setkey config files)



Best Regards,



Frederic






--
Frédéric ROUDAUT
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tl: +33 (0) 2 99 84 71 44, Fax: +33 (0) 2 99 84 71 71




___
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev


  






ESP_example_hex_keys.tgz
Description: application/compressed-tar


packet_ipsec.c.gz
Description: GNU Zip compressed data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Problem with docbook build process

2006-09-07 Thread Joerg Mayer

Hello,

for some reasons not really clear to me, the build process for the
documentation tries to download some files from the docbook repository:

 34.327847   192.168.0.3 -> 217.237.150.115 DNS Standard query A 
docbook.sourceforge.net
 34.391786  217.237.150.115 -> 192.168.0.3  DNS Standard query response CNAME 
projects.sourceforge.net A 66.35.250.209

127.636718   192.168.0.3 -> 66.35.250.209 HTTP GET /release/images/draft.png 
HTTP/1.1

Ideas what is going wrong here?

 Ciao
Joerg
-- 
Joerg Mayer   <[EMAIL PROTECTED]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] tcp_dissect_pdus

2006-09-07 Thread ronnie sahlberg

Are you using the latest SVN ?I fixed a bug in pdu tracking/reassembly about ~2 weeks agoOn 9/8/06, John R. <
[EMAIL PROTECTED]> wrote:OK, so I'm digging into desegment_tcp.What I find is that when segment B comes it looks for the most recent
prior PDU which it calls msp. It calculates an offset and length forthe last snippet of Segment A. The length is 4, which is the length ofdata at the end of Segment A. It uses this info in a call tofragment_add. Later it gets into the if (ipfd_head) { and creates
next_tvb based on the data in *ipfd_head, and makes this next_tvb achild of tvb. I'm not sure what the significance of this last step is.So one ofa) tvb_ensure_length_remaining/compute_offset_length are not working
properly and returning 6 (instead of around 1400 bytes that are inSegment B).b) Problem in fragment_add that leaves the length as 6 instead of~1400... does fragment_add actually affect tvb? It is not clear to me
how the fragment_add, which is passed tvb of Segment B and ipfd_head,and the next_tvb/tvb child/parent business relate.It doesn't appear that compute_offset_length peers into child nodes soI guess fragment_add is the culprit. The tvb would have to consist of
the final desegmented pdu (and then some) once fragment_add returns.I'm new to this codebase so this stuff is pretty opaque to me. Isthere an architecture document I should be reading first? Anyway, any
explanation of how this desegmentation stuff is supposed to work wouldbe helpful.Thanks,-- John.___Wireshark-dev mailing list
Wireshark-dev@wireshark.orghttp://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

43 matches

Mail list logo