full-disclosure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: idea 

On Fri, 19 Sep 2003 12:03:46 PDT, D B <geggam692000@...oo.com>  said:
> does an application exist that encrypts data via pgp
> (gpg) then breaks that up into chunks .... then
> connects to a remote computer via ssl and sends one
> chunk , the order picked at random, then requests a
> different port to be opened ....sends the second chunk
> ... so on to conclusion 
> 
> with the ports being a random selection , the size of
> the chunks being random, and the only info passed
> about the chunks to the other comp would be the order
> they were supposed to go back into

Actually, you need to pass more info than that.  In particular, you need to
find some way for the two ends to agree what the next port to use is, and how
much data to transfer.  If one side is waiting to catch on port 9945 and the
other end sends on 18462, things get messy.  Similarly if one end is expecting
the next blob of data to be 19945 bytes and the other end sends 17594 and then
port-hops.  Two ways come to mind:

1) Use a shared secret between the two ends to initialize a pseudorandom
sequence at both ends, and have each "turn of the crank" pop out the next port/
length info.

2) Use a shared secret with a symmetric cypher such as IDEA, and just embed "go
to port N" or "next block length M" in your data stream.  If you were really
ambitious, you'd use Diffie-Hellman or some such to on-the-fly generate a
shared secret to initialize the symmetric cypher.

In addition, you'd want at least some basic authentication of some sort, so
both ends can satisfy themselves there's no MITM games going on...

Making it work through a firewall or NAT would be challenging - you might have
to settle for a list of 10-12 ports likely to be passed, and for each port
disguise that block as something reasonable for that port - an HTTP POST
request, encoded into NTP packets, on the SMTP port look like a random Outlook
virus, etc.....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030919/40b7c08b/attachment.bin