QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Navigation |
< Proof-of-concept hack for encrypted direct messages on Twitter | The future of OpenStorage - or: Opensolaris Storage Summit >
DeniableMonday, February 23. 2009Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Hi,
it's better not to be caught with the private key in your pockets or with a key that someone else had put in your pocket. And you better withstand some 'social engineering' tactics with hot coals or pincers. I hope most of us have their notebook harddisks encrypted for example. But how long can you stand if someone is beating you with a watschboing? IMHO this is one of the problems we are facing.
#1
on
2009-02-23 18:38
When you arenīt named as the receipient there is no hint pointing to you having the knowledge of the key, so it gets less probable that they warm the coals for you.
It is possible to find out the recipient's public key ID from looking at the ciphertext. Just try to decrypt it without having any secret keys in your keyring:
GNUPGHOME=/tmp gpg --no-default-keyring foo.gpg Use "--throw-keyids" during encryption to avoid this.
This would be one of the issues someone would have to solve in the case she or he wants to implment this outside a hack.
So you're writing up an article about deniability and then choose to ignore the major flaw in your architecture? That's just plain irresponsible. What you have here is not a "hack" but a stupid recipe for trouble.
![]()
Hi,
even if the identity of the participants is obscured by an approach it's sometimes enough to be suspected to be the owner of the key. According to a police chief from Frankfurt IIRC it's OK to hurt people to bring them to a point where they confess everything you want. The police chiefs statement led to far less opposition from our democratic parties than desired. Again, IMHO this is the way we are going. Maybe we can find technical solutions for this problems (Some people don't name this a problem, but I do), but I guess we need some other sharper tool.
#2.2
on
2009-02-24 10:36
The deniablity was just an add-on and not part of the original idea. Just an afterthought.
To fix this, i just have to add some gpg options .... the code isnīt meant for production, thus flagged as proof-of-concept ...
You can encrypt in shared secret key, optionally sign with a public key. Now, the person who posts such a message on a dead drop is always susceptible to the hot coal treatment, and if they know the recipient or any clues to finding the recipient, then the recipient is in trouble.
Also, ciphertext is pretty obvious. Steganography is not going to help you in Twitter, so you'll be limited to very small, coded-but-not-encrypted messages. For bulk espionage this just won't do. More nefarious uses are another story; for those the number of dead drops that could be used abound.
#4
on
2009-02-25 01:15
The author does not allow comments to this entry
|
The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Comments
about Mon, 01.05.2017 11:21
Thank you for many interesting
blog posts. Good luck with al
l new endeavours!
about Fri, 28.04.2017 13:47
At least with ZFS this isn't c
orrect. A rmdir for example do
esn't trigger a zil_commit, as
long as you don't speci [...]
about Thu, 27.04.2017 22:31
You say:
"The following dat
a modifying procedures are syn
chronous: WRITE (with stable f
lag set to FILE_SYNC), C [...]
|