RE: aid worker stego
My response is totally off topic, but this stinks. This is exactly why workers from reputable aid agencies operate under pre-agreed legal status agreements with the country concerned. These agreements cover, among other things, telecommunications infrastructure and legal immunities. Aid agencies that _don't_ do that are part of the reason why the more paranoid governments are reluctant to allow any foreign aid, and I feel somewhat ashamed that people are apparently involved in looking for ways to secretly transmit information without the knowledge and accord of the host state. Every aid worker operating in 'difficult' countries has potential issues with how much they can communicate - both internally to their organisation and externally, but to attempt to communicate in this fashion amounts, quite simply (and probably in legal terms), to espionage. I would suggest that you advise your correspondant to discontinue this line of enquiry - for their own good and that of the aid community at large. "Not getting caught" is a derivation of "the ends justify the means". ben > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter > Fairbrother > Sent: Tuesday, March 29, 2005 9:45 AM > To: cryptography@metzdowd.com > Subject: aid worker stego > > I've been asked to advise an aid worker about stego. Potential major > government attacker. > > I don't think there is much danger of severe torture, but I > don't think > "innocent-until-proven-guilty" applies either, and suspicion should be > minimised or avoided. > > > > I though about recommending Best/Drive -Crypt as they are supposedly > general-purpose encryption programs which can also do > encrypted containers > which are undetectable, but I don't know if that's actually > so, or which to > choose. > > If he's using Windows will they clean up the temp and swap files? > > > > An alternative is a stego program to hide data in eg images. > I don't know > which are the better ones now available, can anyone advise? > > The other point is that the stego program itself will be > visible on disk. Is > there a small stego program that you could eg hide in an > image and somehow > bootstrap from something totally innocuous? > > > > > Any other ideas? > > > -- > Peter Fairbrother > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: SSL/TLS passive sniffing
OK, Ian and I are, rightly or wrongly, on the same page here. Obviously my choice of the word certificate has caused confusion. [David Wagner] > This sounds very confused. Certs are public. How would > knowing a copy > of the server cert help me to decrypt SSL traffic that I have > intercepted? Yes, sorry, what I _meant_ was the whole certificate file, PFX style, also containing private keys. I assure you, I'm not confused, just perhaps guilty of verbal shortcuts. I should, perhaps, have not characterised myself as 'bumbling enthusiast', to avoid the confusion with 'idiot'. :/ [...] > Ian Grigg writes: > >I note that disctinction well! Certificate based systems > >are totally vulnerable to a passive sniffing attack if the > >attacker can get the key. Whereas Diffie Hellman is not, > >on the face of it. Very curious... > > No, that is not accurate. Diffie-Hellman is also insecure if > the "private > key" is revealed to the adversary. The "private key" for > Diffie-Hellman > is the private exponent. No, I'm not talking about escrowing DH exponents. I'm talking about modes like in IPSec-IKE where there is a signed DH exchange using ephemeral DH exponents - this continues to resist passive sniffing if the _signing_ keys have somehow been compromised, unless I have somehow fallen on my head and missed something. > Perhaps the distinction you had in mind is forward secrecy. Yes and no. Forward secrecy is certainly at the root of my question, with regards to the RSA modes not providing it and certain of the DH modes doing so. :) Thanks! ben - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
SSL/TLS passive sniffing
Hi all, I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of security expertise. Recently a discussion came up on firewall-wizards about passively sniffing SSL traffic by a third party, using a copy of the server cert (for, eg, IDS purposes). There was some question about whether this is possible for connections that use client-certs, since it looks to me from the spec that those connections should be using one of the Diffie Hellman cipher suites, which is obviously not vulnerable to a passive sniffing 'attack'. Active 'attacks' will obviously still work. Bear in mind that we're talking about deliberate undermining of the SSL connection by organisations, usually against their website users (without talking about the goodness, badness or legality of that), so "how do they get the private keys" isn't relevant. However, I was wondering why the implementors chose the construction used with the RSA suites, where the client PMS is encrypted with the server's public key and sent along - it seems to make this kind of escrowed passive sniffing very easy. I can't think why they didn't use something based on DH - sure you only authenticate one side of the connection, but who cares? Was it simply to save one setup packet? Anyone know? Cheers, ben - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
