Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto

[Natanael]

I don't see why you'd want split keys when it's already homomorphic.
What would be the additional gain of that?
Unless they need half the key to do the homomorphic computations.

Also, homomorphic encryption and computation is usually slow. VERY slow.

On Sun, Feb 19, 2012 at 17:22, Nico Williams n...@cryptonector.com wrote:

 On Sun, Feb 19, 2012 at 10:08 AM, Florian Weimer f...@deneb.enyo.de wrote:
  * Saqib Ali:
 
  Can somebody explain me how this so-called Homomorphic split-key
  encryption works?
 
  Isn't this just a protocal which performs a cryptographic primitive
  using split key material, without actually recombining the keys?
  (Traditional Shamir secret sharing needs a trust party for key
  recombination.)

 The key part is the homomorphism.  ISTR this from a few years ago, and
 I see wikipedia has an OK article on the subject:


 http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_homomorphic_encryption

 The idea is that you could even write an entire program this way,
 which allows you to run it on untrusted systems without leaking the
 program or data to those systems.  It seems unlikely to get deployed
 anytime soon.

 Nico
 --
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto

[Natanael]

There are multiparty computation too, but that's a bit different since it's
essentially an encrypted VM where everybody runs one part. It could do the
same thing without a snigle trusted party, though.

On Sun, Feb 19, 2012 at 22:34, James A. Donald jam...@echeque.com wrote:

 On 2012-02-20 2:08 AM, Florian Weimer wrote:
  Can somebody explain me how this so-called Homomorphic split-key
  encryption works?

 Homomorphic means you combine the keys without finding out the key that
 you are combining - Everyone gives you an encrypted copy of their key
 fragment, and when you are done, you have an encrypted copy of the combined
 key.



  Isn't this just a protocal which performs a cryptographic primitive
  using split key material, without actually recombining the keys?
  (Traditional Shamir secret sharing needs a trust party for key
  recombination.)
 
  If yes, you might want to look for RSA Threshold Cryptography and
  similar work.

 My understanding is that RSA Threshold always requires a trusted party,
 which makes it useless.  If you have a party that is actually trusted, just
 let him count the votes or whatever.  The cryptography does not do you any
 good.

 The only protocol that I am aware of that performs cryptographic
 operations on a split key with needing a trusted party,  uses Gap Diffie
 Hellman groups.

 All known Gap Diffie Hellman Groups consist of an elliptic curve which
 supports a bilinear pairing from the curve to integers modulo some large
 prime.

 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] (off-topic) Bitcoin is a repeated lesson in cryptography applications - was endgame

[Natanael]

Hmm... Where have I heard of that idea before...

http://disattention.com/78/digital-currencies-crypto-finance-and-open-source/#ot
https://github.com/FellowTraveler/Open-Transactions
https://github.com/FellowTraveler/Open-Transactions/wiki/FAQ

UNTRACEABLE DIGITAL CASH? … FOR REAL?
 Is this the real stuff? With blinded tokens? As in, invented by David
Chaum?
Yes, Open Transactions provides a full and working implementation of
Chaumian blinded tokens. Specifically, the Wagner variant as implemented by
Ben Laurie in his Lucre Project

It works just fine with Bitcoins.

On Mon, Feb 27, 2012 at 21:53, James A. Donald jam...@echeque.com wrote:

 [Another key bitcoin flaw is that it's not particularly anonymous
 in the face of NSA-level network surveillance.  Cash *is* (remains)
 under these conditions.]


 On 2012-02-27 10:26 PM, lodewijk andré de la porte wrote:

 Working on this. And the network problem.


 What is the plan?

 Seems to me that what bitcoin needs is banking layer on top of the
bitcoin layer to issue chaumian coins, with bitcoins acting as gold for the
banks as in free banking (with the potential for ponzis and bank failure.

 Of course bitcoin banks are unavoidably capable of doing a ponzi, thus
one should not keep bitcoins in them for very long periods.


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [OT] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)

[Natanael]

NSA flamebait? Hehe.

On Sat, Mar 24, 2012 at 18:14, Jeffrey Walton noloa...@gmail.com wrote:

 On Fri, Mar 23, 2012 at 8:08 PM, Randall  Webmail rv...@insightbb.com
 wrote:
  From: Jeffrey I. Schiller j...@qyv.net
 
 I bet everyone on this list can send encrypted messages to each other
 and they will never be broken... because they probably already know
 who we all are and (at least I hope) have put us all in the mostly
 harmless bucket.
 
  The people who missed the breakup of the USSR, the first WTC bombing,
 the Underwear Bomber, 9/11 and the bombing of the Murrah Building also
 put US Senator Edward M. Kennedy on the no-fly list.
 I think they got that one right :)

 Kennedy was a liar, cheat, and murdered. I'm pissed off he was even
 allowed to legislate, and the jerk sat on committees that influenced
 legislation that applied to me and my fellow citizens.

 Since justice did not catch up with him in life, I was honored to
 observe his demise and death. My only regret is he did not die sooner.

 Jeff
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] non-decryptable encryption

[Natanael]

What I think people react on is that it's really pointless to use decimals
and having to keep track of when they repeat. A simple RNG with normal
numbers could be used instead, and probably *should* be used unless your
crypto really *needs* numbers consisting of primes divided by primes.

So essentially, they hang up on repeating decimals since they expect there
to be a reason for why they are needed which they can't find, but there are
none AFAIK.

- Sent from my tablet
Den 19 jun 2012 12:03 skrev Givonne Cirkin givo...@37.com:

 of course this would fail at the first repeat.  briefly stated in the
 article in fact. the point made is, that until the first repeat you get a
 sequence of non-repeating digits.  and, we can generate such a sequence, a
 repeating decimal--by equation.  so, why not choose the right length
 repeating decimal for a message of a given length.

 i don't understand why is it clear to some  they get it right away.  why
 do others not see it?  i thought i was clear to use the sequence up until
 the first repeat.

 --- jam...@echeque.com wrote:

 From: James A. Donald jam...@echeque.com
 To: cryptography@randombit.net
 Subject: Re: [cryptography] non-decryptable encryption
 Date: Tue, 19 Jun 2012 17:02:27 +1000

 On 2012-06-18 8:56 PM, Givonne Cirkin wrote:
  Hi,
 
  My name is Givon Zirkind.  I am a computer scientist.  I developed a
 method of
  encryption that is not decryptable by method.
  You can read my paper at: http://bit.ly/Kov1DE
 
  My colleagues agree with me.  But, I have not been able to get pass peer
 review
  and publish this paper.  In my opinion, the refutations are ridiculous
 and just
  attacks -- clear misunderstandings of the methods.  They do not explain
 my
  methods and say why they do not work.
 
  I have a 2nd paper: http://bit.ly/LjrM61
  This paper also couldn't get published.  This too I was told doesn't
 follow the
  norm and is not non-decryptable.  Which I find odd, because it is merely
 the
  tweaking of an already known method of using prime numbers.

 This fails at the first repeat, and has no relationship to the already
 known method of using prime numbers.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography




 _
 You @ 37.com - The world's easiest free Email address !
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] non-decryptable encryption

[Natanael]

I think your problems are these:

You don't understand what makes XOR (one time pad crypto) uncrackable (and
*that* is the term you want, not undecryptable).

You can't explain the advantage of your system well.

It would be vulnerable to timing attacks if implemented (the time it takes
reveals data).

Those infinite varations are possible with other algorithms as well, just
add random padding in the messages.

You don't explain HOW the reciever will know how to decrypt. Compare with
encryption modes for AES: CBC, XTS, counter mode, ECB... You must tell the
recipient what you are using. This can't be encrypted, or else the method
of encrypting *that* info might as well be uses for encrypting the whole
thing.

- Sent from my tablet
Den 19 jun 2012 12:39 skrev Givonne Cirkin givo...@37.com:

 preferring one method to another, is a personal choice i understand.  but,
 to be just off, i don't get.  if no one understands, i need to stop 
 rethink  make a better presentation.  if some get it  some don't,
 depending how many, again i have to reassess my presentation.  there's one
 in every crowd.  more than one or two though...

 i also understand that this method would fail with brute force if the
 message were too small.  but, in between all the primes we can find
 non-repeating sequences of any given length.

 but, how secure do u need?  pgp is secure but decryptable.  but, good
 enough for most ppl.  I stand by phil zimmerman's point.  most ppl use
 envelopes.  easily opened.  but a good deterent.

 --- natanae...@gmail.com wrote:

 From: Natanael natanae...@gmail.com
 To: givo...@37.com
 Cc: cryptography@randombit.net, jam...@echeque.com
 Subject: Re: [cryptography] non-decryptable encryption
 Date: Tue, 19 Jun 2012 12:07:26 +0200

 What I think people react on is that it's really pointless to use decimals
 and having to keep track of when they repeat. A simple RNG with normal
 numbers could be used instead, and probably *should* be used unless your
 crypto really *needs* numbers consisting of primes divided by primes.

 So essentially, they hang up on repeating decimals since they expect there
 to be a reason for why they are needed which they can't find, but there are
 none AFAIK.

 - Sent from my tablet
 Den 19 jun 2012 12:03 skrev Givonne Cirkin givo...@37.com:

 of course this would fail at the first repeat.  briefly stated in the
 article in fact. the point made is, that until the first repeat you get a
 sequence of non-repeating digits.  and, we can generate such a sequence, a
 repeating decimal--by equation.  so, why not choose the right length
 repeating decimal for a message of a given length.

 i don't understand why is it clear to some  they get it right away.  why
 do others not see it?  i thought i was clear to use the sequence up until
 the first repeat.

 --- jam...@echeque.com wrote:

 From: James A. Donald jam...@echeque.com
 To: cryptography@randombit.net
 Subject: Re: [cryptography] non-decryptable encryption
 Date: Tue, 19 Jun 2012 17:02:27 +1000

 On 2012-06-18 8:56 PM, Givonne Cirkin wrote:
  Hi,
 
  My name is Givon Zirkind.  I am a computer scientist.  I developed a
 method of
  encryption that is not decryptable by method.
  You can read my paper at: http://bit.ly/Kov1DE
 
  My colleagues agree with me.  But, I have not been able to get pass peer
 review
  and publish this paper.  In my opinion, the refutations are ridiculous
 and just
  attacks -- clear misunderstandings of the methods.  They do not explain
 my
  methods and say why they do not work.
 
  I have a 2nd paper: http://bit.ly/LjrM61
  This paper also couldn't get published.  This too I was told doesn't
 follow the
  norm and is not non-decryptable.  Which I find odd, because it is merely
 the
  tweaking of an already known method of using prime numbers.

 This fails at the first repeat, and has no relationship to the already
 known method of using prime numbers.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography




 _
 You @ 37.com - The world's easiest free Email address !
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography



 --
 You @ 37.com - The world's easiest free Email address !

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] non-decryptable encryption

[Natanael]

Not 10^500. That's assuming all numbers are primes. With larger numbers,
the ratio of prime numbers to ordinary drops. A lot. I don't think it's
more than 1^50 primes there, could be far less.

Also, you are SERIOUSLY underestimating cryptoanalysis. You assume to much
about how well these tricks will be able to prevent cracking the crypto.

Also, cryptoanalysis often provide attacks that is faster-than-bruteforce
to get the key or plaintext. Now we are talking millions of times faster.
Or more...
You have not convinced me that an FPGA can't crack this in an hour.

- Sent from my tablet
Den 20 jun 2012 19:50 skrev Givonne Cirkin givo...@37.com:

 ok. lets say 500 characters with a random sequence -a prime key- can be
 brute forced decrypted. that's 10^500 combinations.


  now, if implementing my method, in the simplest of forms, it would be
 10^500 * 8!^500 (factorial). is that still decryptable by brute force?


  However, I did add the dimension of not using base 2 or ASCII as I
 discuss in my article. so you have to go back and do it all again at least
 a second time for the several bases I mentioned. So, 3*(10^500 * 8!^500
 (factorial).


  as i mention in my article, a ciphertext of 500 characters could be an
 encrypt of a plaintext of 500 or 375 or 250 characters. so, each possible
 merge has to first be removed. Then, brute forced decrypted. The equation
 for mask calculation was mentioned, but not inserted into the article. That
 would exceeded submission lengths.


  however, implementing my method with masking/merging would potentially
 variably alter the message length. taking simpler methods that i described
 in my paper, of a mask of 8 or 4 bits in a 16 bit data stream (see the
 illustration in the article), the number of masks would be 84,480  7,280
 respectively. These too would have to be removed.


  The following includes only 2 of 15 possibilities.


  So, [84,480*(3*10^250*(8!)^250)]+[7,280*(3*10^375*(8!)^375)]+[3*10^500 *
 (8!)^500].


  Are we still in the realm of brute force?

 you are definitely not rude.  and, yeah, making a discovery or invention
 in encryption, has got to be very rare.  that is why i ran this by every
 math professor  colleague i knew, before submission.  easy to err on this
 things.

 --- jd.cypherpu...@gmail.com wrote:

 From: jd.cypherpunks jd.cypherpu...@gmail.com
 To: givo...@37.com givo...@37.com
 Cc: Natanael natanae...@gmail.com, cryptography@randombit.net 
 cryptography@randombit.net
 Subject: Re: [cryptography] non-decryptable encryption
 Date: Mon, 18 Jun 2012 18:20:13 +0200

 Natanael natanae...@gmail.com wrote:

 One: On the second paper, you assume a prime number as long as the message
 is secure, and give an example of a message of 500 characters. Assuming
 ASCII coding and compression, that will be just a few hundred bits. RSA
 (using primes too) of 1024 bits is now being considered insecure by more
 and more people. I'm afraid that simple bruteforce could break your scheme
 quite fast. Also, why not use simple XOR in that case?


 Yep - bruteforce will work here.
 btw - when it comes to 'non-decryptable encryption' I still like OTP. :)
 Read or re-read Steven Bellovins wonderfull piece about Frank Miller, the
 Inventor of the One-Time Pad
 https://mice.cs.columbia.edu/getTechreport.php?techreportID=1460

 I'm not a rude guy and try not to diminish your archievments but there's
 some truth in the following sentence: Even if clever beyond description the
 odds that someone without too much experience in the field can
 revolutionize cryptography are small. Can't remember who said this - or
 something similar to this - but it's true anyhow. Think about this every
 time when I try to 'invent' something within my fields. :)

 --Michael



 Den 18 jun 2012 12:56 skrev Givonne Cirkin givo...@37.com:

 Hi,

 My name is Givon Zirkind.  I am a computer scientist.  I developed a
 method of encryption that is not decryptable by method.
 You can read my paper at: http://bit.ly/Kov1DE

 My colleagues agree with me.  But, I have not been able to get pass peer
 review and publish this paper.  In my opinion, the refutations are
 ridiculous and just attacks -- clear misunderstandings of the methods.
 They do not explain my methods and say why they do not work.

 I have a 2nd paper:  http://bit.ly/LjrM61
 This paper also couldn't get published.  This too I was told doesn't
 follow the norm and is not non-decryptable.  Which I find odd, because it
 is merely the tweaking of an already known method of using prime numbers.

 I am asking the hacking community for help.  Help me test my methods.  The
 following message is encrypted using one of my new methods.  Logically, it
 should not be decryptable by method.  If you can decrypt it, please let
 me know you did  how.

 CipherText:


 113-5-95-5-65-46-108-108-92-96-54-23-51-163-30-7-34-117-117-30-110-36-12-102-99-30-77-102

 Thanks.

 I have a website about this:  www.givonzirkind.weebly.com
 For information about

Re: [cryptography] encrypted bloom filter protocols with unlinkable queries

[Natanael]

Never trust that the server delete data.

- Sent from my tablet
Den 21 jul 2012 11:15 skrev cryptoquesti...@safe-mail.net:

 Hello, I have a question regarding encrypted bloom filter protocols. I
 have come to the understanding that I can use such protocols to allow a
 client to query a server for the presence of a string, string. Due to the
 properties of the encrypted bloom filter protocol, the server is incapable
 of determining that the client is checking for the presence of string.
 However, what interests me is if any of these protocols also support
 unlinkable queries, such that a client making multiple queries for the
 presence of string does not reveal to the server over a set of queries
 that they are checking for the presence of the same string in each query,
 even if the server is incapable of determining which specific string the
 client is checking for the presence of.

 I have been looking at a few encrypted bloom filter protocols and I do not
 fully understand them yet, but before I spend the required time to figure
 one out I would like to make sure that it has this property. One potential
 solution I can think of is perhaps the servers can keep copies of the items
 which they index (which are themselves very small, around 128 bytes) and
 every cycle (ie: ten minutes) they hash the items with a hashing function
 keyed with a value computable by the client and the server (ie: the time in
 UTC exactly ten minutes ago when the previous cycle started), and then add
 these items to a new bloom filter and delete the previous bloom filter. Now
 if clients query the encrypted bloom filter no more than once per cycle, I
 believe unlinkability may be gained (if it was not there in the first
 place), as by definition the server is incapable of determining which
 object in the bloom filter than the client is checking for the presence of,
 and the query sent by the
   client must look different as it is technically querying for a
 completely different object than it was in previous cycles. Are there any
 flaw in this?

 Thanks!
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic dead man switch?

[Natanael]

If the trustee (correct word?) stops passing the messages to your CDMS
(cryptographic dead man switch), it would simply decrypt the original
message automatically. So you can not put the entire mechanism in the hands
of the trustee, especially not the part that authorizes the decryption. I
could imagine that you would set up a remote server that would simply send
the secret to the trustee, encrypted to his public key for security, when
you stop pinging it by sending signed messages.

To prevent one server from being compromised and revealing the secret (even
if only to the trustee since it can be pre-encrypted), I could imagine
chained-session Secure Multiparty Computation across several remote
servers. The idea is that you run the SMPC software on your remote servers,
give a large random number to each, they generate a keypair inside the
virtual SMPC machine, and you encrypt the message to that key.The machines
split the keypair among themselves using a Secure Sharing Scheme. You send
that encrypted message to all the machines. Each day the machines re-run
the SMPC, sends their key parts and reassemble them using the secret
sharing scheme inside the SMPC, checks if a signed message have been
recieved from you, and if not it decrypts the secret message to the
trustee. A program on the machines will then see this message as the output
from the SMPC and send it to the trustee.

Overly complicated, maybe, but secure and can actually work.

On Wed, Sep 5, 2012 at 3:51 PM, StealthMonger
stealthmon...@nym.mixmin.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Can there be a cryptographic dead man switch?  A secret is to be
 revealed only if/when signed messages stop appearing.  It is to be
 cryptographically strong and not rely on a trusted other party.

 The motivating application is a Living Trust wherein the Grantor wants
 to keep secret, even from the Trustee, the locations of his caches of
 gold until such time as he is no longer able to send signed messages.
 Each signed message has to somehow avert revelation of the secret for
 another time period (three months, say).

 - --


  -- StealthMonger stealthmon...@nym.mixmin.net
 Long, random latency is part of the price of Internet anonymity.

anonget: Is this anonymous browsing, or what?

 http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain

stealthmail: Hide whether you're doing email, or when, or with whom.
mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


 Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/

 iEYEARECAAYFAlBF1ecACgkQDkU5rhlDCl5omQCgpcuTWhFuojJkkgUOLeZwnYIf
 TlwAnAhrxdyeLMccamIAZ8CbLZKn2jyb
 =MaVJ
 -END PGP SIGNATURE-

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] abstract: Air to Ground Quantum Key Distribution

[Natanael]

Does anybody here take quantum crypto seriously? Just wondering. I do not
see any benefit over classical methods. If one trusts the entire link and
knows it's not MitM'd in advance, what advantage if any does quantum key
distribution have over ordinary methods? And isn't it just as useless
otherwise as the ordinary methods?

- Sent from my tablet
Den 18 sep 2012 17:20 skrev d...@geer.org:


 http://www.qcrypt.net/docs/extended-abstracts/qcrypt2012_submission_12.pdf

 QCrypt, Singapore, 12 September 2012

 Air to Ground Quantum Key Distribution

 Sebastian Nauerth1, Florian Moll, Markus Rau1, Christian Fuchs,
 Joachim Horwath and Harald Weinfurter1

 The range of quantum key distribution (QKD) systems is known to be
 limited to a few hundreds of km due to the attenuation of the channel
 and the finite signal to noise ratio of available detectors. Satellite
 based systems, however, could provide efficient links for global
 scale QKD. While both classical satellite downlinks and long range
 terrestrial free-space QKD were shown successfully, a quantum key
 exchange with a rapidly moving platform is still missing.  Here we
 report on the first experimental demonstration of a BB84 QKD
 transmission from an airplane at a speed of 290 km/h to ground. Our
 system uses attenuated laser pulses with a mean photon number of
 mu=0.5 and polarization encoding. Over a distance of 20 km a stable
 link was achieved for 10 min yielding a sifted key rate of 145
 bits/s with a quantum bit error rate (QBER) of 4.8 %.

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] abstract: Air to Ground Quantum Key Distribution

[Natanael]

It can detect passive snooping, not full MITM.

- Sent from my tablet
Den 18 sep 2012 18:17 skrev Zack Weinberg zack.weinb...@sv.cmu.edu:

 On Tue, Sep 18, 2012 at 3:30 PM, Natanael natanae...@gmail.com wrote:
  Does anybody here take quantum crypto seriously? Just wondering. I do not
  see any benefit over classical methods. If one trusts the entire link and
  knows it's not MitM'd in advance, what advantage if any does quantum key
  distribution have over ordinary methods? And isn't it just as useless
  otherwise as the ordinary methods?

 I've seen claims that quantum key agreement lets both parties detect a
 man in the middle with no prior communication and no trusted third
 party.  If that's true it would obviously be huge.  I don't know
 enough about the topic to assess whether it's actually true.

 It seems obvious to me that you'd only use quantum crypto to set up
 symmetric keys for a secure channel, just like you don't use RSA for
 bulk encryption right now.

 zw

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic dead man switch?

[Natanael]

But you can't revoke his ability to keep bruteforcing the message.

- Sent from my tablet
Den 19 sep 2012 23:01 skrev mhey...@gmail.com mhey...@gmail.com:

 Doh, don't know why I brought public-key crypto into this. There isn't
 a need for it. Just pick, say, an AES key and give the trustee some of
 the key's bits so they only have to brute force part of the key.

 On Wed, Sep 19, 2012 at 4:48 PM, mhey...@gmail.com mhey...@gmail.com
 wrote:
  On Wed, Sep 5, 2012 at 9:51 AM, StealthMonger
  stealthmon...@nym.mixmin.net wrote:
  -BEGIN PGP SIGNED MESSAGE-
 
  Can there be a cryptographic dead man switch?  A secret is to be
  revealed only if/when signed messages stop appearing.  It is to be
  cryptographically strong and not rely on a trusted other party.
 
  Every three months I, the Grantor, encrypt my secret in a new
  secret-encrypting-key and place that secret in my box. (I keep my box
  away from others - maybe put it in a safe).
 
  I also encrypt that secret-encrypting key in a public key but not too
  strong a public key, one that can be broken in three months time.
 
  I then throw away the private key to that public key (I don't need it,
  I know my secret).
 
  I give the public-key encrypted secret-encrypting key to the trustee,
  heck I can publish it on the web if I want.
 
  If I should die, I will stop re-encrypting the secret and the trustee
  (that I never really trusted) can break the public key and get to the
  secret.
 
  I know a second scheme that we worked out years ago when one of our
  group was working on DTN (delay tolerant networking) where we would
  encrypt something and bounce the encrypting key off a distant node and
  get a few seconds or minutes of safe time until the something could
  get decrypted. This scheme has the benefit of not failing if some
  whiz-bang new crypto breaking system comes along but deals with much
  shorter time periods. I assume that if I'm using the crypto-only
  method, then I will keep apprised of whiz-bang new crypto breaking
  systems and re-encrypt early with a larger key to get back on my three
  month schedule if such a faster breaking system should appear.
  
  Michael Heyman
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic dead man switch?

[Natanael]

By the way, using SMPC remotely can be generalized beyond Dead Man Switch
pretty easily (IMHO). While SMPC actually isn't needed to do a DMS, just
secret sharing, SMPC lets you hide the terms for when to release the
secret, and even to change the terms while keeping them secret. Here's how:

First one creates a scripting engine that can run inside the SMPC. This can
be a Python or Bash port if one wants that. Then one writes a script that
will run inside the SMPC that during the first run that takes shares from a
secret sharing scheme. Each node gets different shares.

The data in these shares then contain a flag that says first run, an
asymmetric key (generated by you in advance), the secret data and a script
with the actual conditions for releasing the secret. Then the loader script
assembles the shares and run that conditions script. That script also see
that this is the first run. So it gives certain commands to the software on
the outside of the SMPC as it's output. This can be look for X at website
Y every Z hours, and run me again in 6 hours or whatever. The response is
given in a certain format the script can understand as input during the
next run of the SMPC.

The internal state in the SMPC with all the data and code we want to save
is encrypted and split in new shares (Grantor was last heard of
2021-06-12; run code X next time?), this is part of the output and tagged
as the input shares for the next SMPC run. This replaces the original
shares. As the input fetched to the SMPC can contain new code, you can give
the SMPC new instructions this way. The new code in the SMPC can also give
new commands to the code outside the SMPC (that code that runs the SMPC and
fetch and pass on data).

The data the SMPC scheme is supposed to fetch should be both encrypted to
it's public key and signed by your public key (you have to give the SMPC
your public key then too, obviously).

So you rent a bunch of servers online, anonymously, and set up this SMPC
scheme on it.

So, what would you guys run on this thing? Remember that the overhead makes
it slooow, so no secret bruteforcing of anything.

- Sent from my tablet
Den 5 sep 2012 16:21 skrev Natanael natanae...@gmail.com:

 If the trustee (correct word?) stops passing the messages to your CDMS
 (cryptographic dead man switch), it would simply decrypt the original
 message automatically. So you can not put the entire mechanism in the hands
 of the trustee, especially not the part that authorizes the decryption. I
 could imagine that you would set up a remote server that would simply send
 the secret to the trustee, encrypted to his public key for security, when
 you stop pinging it by sending signed messages.

 To prevent one server from being compromised and revealing the secret
 (even if only to the trustee since it can be pre-encrypted), I could
 imagine chained-session Secure Multiparty Computation across several remote
 servers. The idea is that you run the SMPC software on your remote servers,
 give a large random number to each, they generate a keypair inside the
 virtual SMPC machine, and you encrypt the message to that key.The machines
 split the keypair among themselves using a Secure Sharing Scheme. You send
 that encrypted message to all the machines. Each day the machines re-run
 the SMPC, sends their key parts and reassemble them using the secret
 sharing scheme inside the SMPC, checks if a signed message have been
 recieved from you, and if not it decrypts the secret message to the
 trustee. A program on the machines will then see this message as the output
 from the SMPC and send it to the trustee.

 Overly complicated, maybe, but secure and can actually work.

 On Wed, Sep 5, 2012 at 3:51 PM, StealthMonger 
 stealthmon...@nym.mixmin.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Can there be a cryptographic dead man switch?  A secret is to be
 revealed only if/when signed messages stop appearing.  It is to be
 cryptographically strong and not rely on a trusted other party.

 The motivating application is a Living Trust wherein the Grantor wants
 to keep secret, even from the Trustee, the locations of his caches of
 gold until such time as he is no longer able to send signed messages.
 Each signed message has to somehow avert revelation of the secret for
 another time period (three months, say).

 - --


  -- StealthMonger stealthmon...@nym.mixmin.net
 Long, random latency is part of the price of Internet anonymity.

anonget: Is this anonymous browsing, or what?

 http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain

stealthmail: Hide whether you're doing email, or when, or with whom.
mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


 Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net

Re: [cryptography] Can there be a cryptographic dead man switch?

[Natanael]

I can not imagine anything inherently trustable. I do not want to trust
that single server won't be hacked, tapped by NSA or raided by FBI.
Den 22 sep 2012 22:49 skrev StealthMonger stealthmon...@nym.mixmin.net:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 James A. Donald jam...@echeque.com writes:

  On 2012-09-05 11:51 PM, StealthMonger wrote:

  Can there be a cryptographic dead man switch?  A secret is to be
  revealed only if/when signed messages stop appearing.  It is to be
  cryptographically strong and not rely on a trusted other party.

  Such a system cannot exist:

  Obviously the messages have to appear on the system that contains the
  secret.  Pull the internet connection.

 Counter-measures to Donald's dilemma have so far involved servers too
 hidden or numerous to simply pull the internet connection.

 Another approach is for the server to be too big to fail, i.e.
 public and widely used, so that a whole business would be destroyed if
 the Internet connection were pulled.

 It wouldn't take much capability in such a server to allow Grantor to
 create a robot there which gives Trustee access to the secret, but
 only if it doesn't hear from the Grantor for some time.  With suitable
 permissions, the Trustee can even be given read-only access the whole
 while to everything except to the secret itself, so that Trustee can
 assure herself that it's all actually there.

 Are there existing public servers that can provide this functionality?
 Google mail?  Zooko's Tahoe?


 - --


  -- StealthMonger stealthmon...@nym.mixmin.net
 Long, random latency is part of the price of Internet anonymity.

anonget: Is this anonymous browsing, or what?

 http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain

stealthmail: Hide whether you're doing email, or when, or with whom.
mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


 Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/

 iEYEARECAAYFAlBd+C8ACgkQDkU5rhlDCl4gmQCeNRJga4jKwFecbsYWi1LgUSv6
 eYsAniTaSeZ8raCBfENb9H+hgdfZ+bxB
 =rty8
 -END PGP SIGNATURE-

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can there be a cryptographic dead man switch?

[Natanael]

In that case Anonymous and other hacker groups is your problem.
Den 23 sep 2012 01:37 skrev StealthMonger stealthmon...@nym.mixmin.net:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Natanael natanae...@gmail.com writes:

  I do not want to trust that single server won't be hacked, tapped by
  NSA or raided by FBI.

 I absolutely agree.  But the adversary here is nothing like NSA or
 FBI, and the stakes are nowhere near threats to any State, and nobody
 has reason to believe otherwise.  Remember, this is basically a
 friendly agreement between Grantor and Trustee and in the category of
 good fences make good neighbors.  Of course, the Trustee, to whose
 key the secret is encrypted the whole while, has to use a strong key
 to keep third parties out.

 - --


  -- StealthMonger stealthmon...@nym.mixmin.net
 Long, random latency is part of the price of Internet anonymity.

anonget: Is this anonymous browsing, or what?

 http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain

stealthmail: Hide whether you're doing email, or when, or with whom.
mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


 Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/

 iEYEARECAAYFAlBeLwgACgkQDkU5rhlDCl6z4wCdFwSXhSi1FarU53U/mlJelwKX
 MN4AnA93gcQ5AnepfiFMq4S5l2K6KGq1
 =L1pU
 -END PGP SIGNATURE-

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] A new form of encryption allows you to compute with data you cannot read

[Natanael]

Homomorphic encryption isn't really that new, it's just that it's starting
to get practical first now.

On Wed, Sep 26, 2012 at 11:49 PM, Moti m...@cyberia.org.il wrote:


 http://www.americanscientist.org/issues/num2/2012/5/alice-and-bob-in-cipherspace/1

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] cjdns review

[Natanael]

AFAIK the key is just generated once and then hashes are generated in two
rounds, if it is 0xFC at the first try it's done, otherwise it runs more
checksum rounds in groups of two.
Den 4 okt 2012 22:55 skrev Guus Sliepen g...@sliepen.org:

 On Thu, Oct 04, 2012 at 02:37:53PM +0200, Eugen Leitl wrote:

  I've recently become interested in cjdns
 http://en.wikipedia.org/wiki/Cjdns
  which apparently used NaCl in UDP over tun when tunneling.
 
  I'm not aware of any review of the entire system, including
  key generation etc.

 Disclaimer: I only read the Wikipedia article and the whitepaper.

 It is very interesting, they use the hash of a public key as the address
 of a
 node. That reminds me of SILC. There is some cost involved in claiming an
 address; one must generate 128 EC keys one average, since the first byte
 of the
 address must always be 0xFC in order to be a valid IPv6 address without
 conflicting with public addresses.

 If you know which node you want to talk to, both peers first generate
 ephemeral
 keys, which are signed and encrypted using NaCl's crypto_box() function.
 Then
 these ephemeral keys will be used to encrypt the real data packets, but
 again
 using crypto_box(). That means asymmetric crypto is used for every packet,
 which makes it VERY slow.

 Not only that; apart from end-to-end encryption and authentication,
 packets are
 also encrypt+authenticed hop-by-hop (unless the peers are direct
 neighbors).
 Given that it is also possible to do a limited form of source routing, this
 might make it robust against traffic analysis and increase anonimity, but
 it
 adds a large burden to intermediate nodes. It also goes against the
 Internet's
 principle of a dumb core with smart edges.

 I do not see an obvious flaw in the key generation, encryption and
 authentication. But in the end, you are not going to remember 120 bit
 addresses, so currently they are just running DNS on top, I guess that is a
 very weak point in cjdns.

 Another issue might be the routing table itself; the whitepaper doesn't
 mention
 much, but the Wikipedia page say they use a DHT similar to Kademlia. I do
 not
 know how well that can route around damage or malicious nodes.

 --
 Met vriendelijke groet / with kind regards,
   Guus Sliepen g...@sliepen.org

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How much does it cost to start a root CA ?

[Natanael]

Bitcoin based DNS? That would be Namecoin. I am unsure if it also manages
SSL or similiar link encryption or if that is a separate thing for the
scheme.
Den 6 jan 2013 08:27 skrev James A. Donald jam...@echeque.com:

 On 2013-01-05 12:07 PM, Morlock Elloi wrote:

 Correct. The cost of being CA is equal to the cost of getting CA signing
 pub key into the target audience browsers.

 You can (sorted by increasing security, starting with zero):

 1 - go through browser vendors,
 2 - have your users to install additional CA key into their existing
 browsers (and perhaps remove others), or
 3 - distribute your own browser package.

 Pick one.


 Most of the browsers are open source.  A fork could be justified by adding
 privacy value or security value, as, for example, SRWare Iron or the Tor
 browser.

 This also applies pressure on the major browsers to refrain from too
 flagrantly violating their customer's privacy.

 Perhaps we need a browser that facilitates communication and interaction
 between the holder of one bitcoin key and the holder of another.
 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bonding or Insuring of CAs?

[Natanael]

On topic for the thread: I don't *think* there's currently any insurance
companies with special policies for CA:s. There might be about 600
organizations that can issue SSL certs according to EFF, but there's more
insurance companies than that in the world. Most of them probably don't
have many CA:s as clients.

---

About what's on/off topic: Well, I guess many would agree that a strong
cryptographic algorithm/protocol is useless if the implementation is bad,
so that would be relevant (like SSL and relying on CA:s). If you are
interested about cryptography, I assume you want it to be used right. But
then again, there's a limit for when it's too far off topic. So I guess the
real question is *what is too off-topic*? I guess we need some consensus
about what's too off topic. It makes sense to talk about why a clever
algorithm that is useless *is* useless (like most of quantum crypto). But
if a question about insurance companies and their incentives to push a CA
to improve security strays into talk about general insurance company
policies or even away from anything related to security or trust, that's
too far off topic IMHO. But a discussion about the incentives for CA:s do
do the right thing seems enough on topic to me, because SSL as designed is
useless without secure CA:s (not considering Perspectives or MonkeySphere
unless either gets momentum enough for widespread use). Making SSL work in
real life is on topic for this list, right? That's what I'm assuming.

If somebody wants there to be a pure cryptography mailing list and separate
more generic one (like this one currently is), I think that person would
have to try starting a more strict crypto mailing list, because I don't
think most people here would want the rules here to get stricter or that
they would want to switch to a different list that would be just like this
one is now. We also don't want too many different lists.


2013/1/25 Paul Hoffman paul.hoff...@vpnc.org

 Since there isn't a strong list moderator here, I gotta ask: is this (and
 similar PKIX-is-broken threads) on-topic for this mailing list? Regardless
 of how much I agree with the sentiment, it seems to have nothing to do with
 cryptography. Maybe someone should set up a post-pki mailing list for such
 threads? (Or maybe I should be less cranky?)

 --Paul Hoffman
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bonding or Insuring of CAs?

[Natanael]

Well, are there more people here who want a more strict crypto only list
than those who want a more generic one? Would we set stricter rules here,
or would there have to be a split? If there would be a split, are there
enough of those who want a stricter list to start a new list and keep it
going?

I would personally not mind a more strict list, but I would find it a bit
boring if nothing but cryptography would be discussed. There's a lot of
interesting consequences from cryptography, and if the only ones we could
discuss here would be what the algorithms and protols themselves does, I
personally don't think as many people would be interested in the
discussions. But then I don't have any data on that, and I don't know how
many or what kind of responses you got.

2013/1/26 Paul Hoffman paul.hoff...@vpnc.org

 On Jan 25, 2013, at 4:11 PM, Natanael natanae...@gmail.com wrote:

  If somebody wants there to be a pure cryptography mailing list and
 separate more generic one (like this one currently is), I think that person
 would have to try starting a more strict crypto mailing list, because I
 don't think most people here would want the rules here to get stricter or
 that they would want to switch to a different list that would be just like
 this one is now.

 The off-list responses to my message would disagree with you.

  We also don't want too many different lists.

 Some of we do. My question was to tease this out a bit.

 I'm happy to shut up about it if I'm in the minority, but the question
 that started this thread was a perfect example of something that is about
 security (actually, security operations), not cryptography, and yet gets
 brought up on this list more and more.

 --Paul Hoffman
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bitmessage

[Natanael]

This is precisely how I2P eepsites work. The true addresses are [52
characters of b32 encoded checksum of public key].b32.i2p while the
hosts.txt file is a list of these with their readable [sitename].i2p
domains. You can modify your own lists as you wish.

I2P Messenger and Bote mail could be combined to do what you suggest. :)

- Sent from my tablet
Den 17 feb 2013 01:39 skrev James A. Donald jam...@echeque.com:

 On 2013-02-17 4:49 AM, Jonathan Warren wrote:


 A primary goal has been to make a clean and simple interface so that the
key management, authentication, and encryption is simple even for people
who do not understand public-key cryptography.

 
 This is of course, the hard problem.

 If I understand correctly what you have done, in the system, true names
are long random non memorable bit strings, and introductions are not
inherently part of the system, nor are petnames part of the system.

 So no one has anyone to talk to, nor anything to talk about, and if they
did, they would have trouble recollecting who they were talking to, since
all truenames look like gibberish, thus all truenames look alike.
 

 A proposed alternative user interface design:

 Seems to me that you need something like public web pages, and something
like a favorites list / bookmarks list, where when you add something or
someone to your list, a petname/truename pair is added to your bookmark
list.

 Note how Tor's browser thinks it is communicating by http, while in
reality communicating by a completely different protocol.

 A link in the webpage would be nickname/truename pair, thus clicking on
such a link, you would be guaranteed to go to where the author the web page
intended (trusted path) and the destination would be capable of being added
to your bookmarks list.  The long random gibberish true name would almost
always be hidden behind nicknames, petnames, and trusted path links.

 When you click on something in your list, you either find yourself on a
webpage(by trusted path), or open a text message window to an individual,
by trusted path.  If the recipient is not currently dealing with your
window, (windows open simultaneously on both machines) messages get saved
and are available in an email like interface, so that instant messaging and
email are variant user interfaces on the same function.


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NSA Releases 136 Cryptologs 1974-1997

[Natanael]

The OCR file link is wrong. Ditch that e in text.

http://cryptome.org/2013/03/nsa-cryptologs-txt.zip

2013/3/20 John Young j...@pipeline.com

 Most of the Cryptologs were formerly classified Top Secret.
 NSA calls it a monumental release.

 Non-searchable image files at NSA:

 http://www.nsa.gov/public_**info/declass/cryptologs.shtmlhttp://www.nsa.gov/public_info/declass/cryptologs.shtml

 The full collection in a Zipped file:

 http://www.governmentattic.**org/7docs/NSA-Cryptolog_1997-**1974.pdfhttp://www.governmentattic.org/7docs/NSA-Cryptolog_1997-1974.pdf(240MB)

 We OCRed the collection to raw text, no formatting, no proofreading
 but fully searchable:

 http://cryptome.org/2013/03/**nsa-cryptologs-text.ziphttp://cryptome.org/2013/03/nsa-cryptologs-text.zip(4.4MB)






 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] A new (hopefully silly) Zerocoin/accumulator question

[Natanael]

From what I have read, and as far as I have understood it, your
zero-knowledge proofs are linked to a specific state of your choice. In
other words, you prove that your Zerocoin mint was one of a certain set of
Zerocoin mints. One can ONLY test the zero-knowledge proof against that set
(since you generated the zero-knowledge proof with a specific accumulator
in the blockchain). So one can't test it against each individual Zerocoin
mint.

This might be incorrect, but I *think* it's how it works.


2013/5/15 Jane th...@angels.la

 Hello, it's me again.

 Upon re-reading Zerocoin paper (
 http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf ), I've noticed
 the following:

 When I mint a Zerocoin, I add my 'c' to the accumulator.
 Accumulator state gets checkpointed at discrete intervals - possibly
 every block, or so.

 Now, let's say I've minted a zerocoin at blockheight N, and an
 accumulator state that includes my 'c' has been checkpointed at
 blockheight N+1

 Now, I wait for 100 blocks and spend my zerocoin, providing relevant
 proofs P and adding relevant serial number to the list of numbers
 spent. This happens at blockheight N+101

 For ease of experiment, I was the only person to mint at blockheight
 N+1, and the only one to  spend at blockheight N+101,  (there were
 some other mints at N+4 though)

 Question:
 Am I correct in thinking that attacker can *NOT* gain information
 regarding the blockheight at which my coin was minted by repeatedly
 trying my (π,S) with different accumulator state checkpoints (which
 come conveniently arranged in chronological order ;-) ) ?

 Something like
 1) test this fine proof and this fine S against accumulator states
 and mint set assembled from blocks from N-100 to N-50...
 2) then try same against N-100 to N...
 3) then, finally, try same against N-100 to N+1

 Would the last step yield anything informative ?

 Hope this makes sense and please pardon my ignorance...

 Best wishes,
  Jane
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel

[Natanael]

My suggestion is that you research the history of (cryptographic)
authentication, mutual authentication (thanks Wikipedia for that phrase)
and MITM. (Maybe you already have done that, though?)

I can at least point out that spy agencies have known for many many decades
that you can not securely and secretly communicate with anybody else
without preparing it in advance. In some way or another, a secret of some
sort must be shared with the intended recipient and only with him. (This
has been discussed in the comments on Schneier's blog, for example.) If
there is no unique knowledge that only your recipient has, you can't send a
message that *only* he can understand. To what extent/how thoroughly do you
need this to be proven in the kind of documents you're looking for?


2013/6/6 Ralph Holz h...@net.in.tum.de

 Hi,

 I am currently doing a write-up that dives into some of the more formal
 aspects of authentication. In particular, I am wondering when exactly it
 was formally proved that two entities A and B cannot establish a secure
 channel between them without such a secure channel having been available
 to them at a previous point in time. Or, in other words, you cannot
 authenticate without already having authenticated credentials for that
 purpose.

 To the best of my knowledge, the earliest such proof is the one by Colin
 Boyd:

 Colin Boyd. Security architecture using formal methods. IEEE Journal on
 Selected Topics in Communications. 1993.

 Does anyone know of an earlier such (formal) proof?

 Ralph

 --
 Ralph Holz
 I8 - Network Architectures and Services
 Technische Universität München
 http://www.net.in.tum.de/de/mitarbeiter/holz/
 Phone +49.89.289.18043
 PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel

[Natanael]

So basically, the way around having one insecure channel is to use so many
insecure channels that the same attacker can't control them all. Which IRL
means you run around between computers and check if what you published is
available under the exact identity/keys you specified, and keep making up
new names until you manage to get one of them widely propagated with your
own keys, and then you keep using that identity.

Note that one of the problems with this is a worse version of
domain-squatting - a powerful attacker can register nearly *all* meaningful
names faster than most regular people. However, this can be made harder
with something like proof-of-work, which interestingly enough things like
vanitygen provides right there in the keys - you specify a text string you
want in your public key (or it's hash), and it generates keys until it
finds a match. People are using this in Bitcoin, and people have done this
for Tor .onion addresses. It could also be done for CJDNS and I2P's b32
domain names ([52-base32-characters-of-hash-of-public-key].b32.i2p). Make
up a unique name and generate a unique key for it, and it's harder to do a
quick MITM on it when you start trying to propagate it.

On quantum encryption/key exchange that was mentioned before - that assumes
just like any other connection that the MITM wasn't in place before the
connection was first put in use. You can detect an attacker that shows up
in between you and the node you are directly physically connected to, but
if he's already there when you first connects then you can't know the
difference. Whatever channel you use to verify the connection, you might as
well just use that channel to exchange asymmetric public keys and skip
everything quantum.


2013/6/7 Guido Witmond gu...@witmond.nl

 On 07-06-13 14:50, ianG wrote:

 On 7/06/13 14:45 PM, Ralph Holz wrote:

 Hi,


  What makes the silk road key the real public key is that it is
 the same key has everyone else uses.- that it is public.


 This simply falls back to an assertion made by a `trusted' entity,
 namely the `public', and is thus an authenticated credential.



 Well, yes or no or maybe.

 In practice, there is no 'entity' named the public [1]. Looking a bit
 closer, there are people, many of them. What broad publication allows
 is a low-cost way to ensure that most people have the same initial
 secret, and that most examples of any interference with that initial
 secret are cheaply discovered.


  PS: Leaving aside the obvious circular definition of trusted
 entity being one who we trust to do the authentication. In the above
  example, it reads absurdly: there is no such entity 'public' that
 decides to do the trusting of the non-existent-entity 'public'.


 This is what I try to do with my Eccentric-authentication scheme. [1]

 I make this 'public' more explicit with a global registry. It allows
 verification that a CA only certifies each Common Name only once.
 The price of this registry is mostly storage and lookups. A DHT-like
 storage would be perfect. There are no namecoin-like hashes to
 calculate. [2]

 There is no need for users to put *trust* in the global registry. The
 registry is not in a position to invalidate any certificates, nor create
 fake certificates.

 All trust comes from verifying that a CA (still) doesn't sign a Common
 Name twice. Only a CA is able to forfeit the trust he's earned by
 signing multiple certificates bearing the same Common Name.

 Even though the CAs (one for each web site) do not validate a users real
 identity, this verification of the uniqueness property allows the
 certificate (and the users' public key) to become an anonymous identity.

 Use:

 The idea is that bloggers at an ecca-authenticated blog write signed
 messages with the message signature attached to their blog entries. The
 user agent verifies these signatures against the verifiable unique
 certificate. This allows people to *identify* fellow bloggers by their
 certificate (Common name). [3]

 The registry operates as introducer. Once a person has communicated
 successfully with someone there is no need to look up their certificates
 at each use. This keeps the load on
 the registry low and improves scalability.

 With DNSSEC/DANE in the mix, we have another way around Zooko's Triangle
 [4]

 Try it:

 It's not only theory. I've got two demo sites and a proxy server to
 stand in for the user. It shows the Local CA bit and anonymous messaging.
 (notice it doesn't use the global registry idea, yet)
 [5]



 With regards, Guido Witmond.



 PS. This is a protocol to create anonymous accounts where anonymity is
 important. Don't use it to identify your employees, nor your customers
 when you run a bank.

 [1] 
 http://eccentric-**authentication.org/http://eccentric-authentication.org/
 [2] http://eccentric-**authentication.org/eccentric-**
 

Re: [cryptography] Project C-43 and Public Key Encryption

[Natanael]

Isn't that equivalent to sender doing XOR on the plaintext, recipient doing
XOR on first ciphertext, sender doing another XOR on second ciphertext to
create third ciphertext, and the recipient doing XOR again to get plaintext?

That's key-reuse and breaks XOR/OTP. The middleman simply XORs the
ciphertexts with each other to get the key and then decrypts the first
ciphertext. He just simply needs to record all ciphertexts. The same basic
method applies for the noise application/removal.
Den 13 jun 2013 17:31 skrev Leandro Meiners lmein...@gmail.com:

 Koenig's idea is interesting, and with a small twist I think could have
 worked. If instead of only applying noise at the receiving end, noise was
 first applied by the sender, then the recipient applies his own noise and
 sends it back to the sender, who then subtracts his original noise and
 sends it back encrypted with the recipient's noise who can now decrypt
 it

 Cheers,
 Leandro.-


 On Thu, Jun 13, 2013 at 3:31 PM, John Young j...@pipeline.com wrote:

 Old Mystery Solved: Project C-43 and Public Key Encryption:

 http://techpinions.com/an-old-**mystery-solved-project-c-43-**
 and-public-key-encryption/**18205http://techpinions.com/an-old-mystery-solved-project-c-43-and-public-key-encryption/18205


 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography




 --
 Leandro Federico Meiners

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] 100 Gbps line rate encryption

[Natanael]

Would anybody dare to use a SHA256 based stream cipher? (XOR with checksum
of key and counter or whatever you want to throw in there.) Would it be
faster than RC4/Salsa20? I'm a bit curious about why nobody seems to be
using hash/checksum based stream ciphers.


2013/6/23 James A. Donald jam...@echeque.com

  On 2013-06-23 6:47 AM, Peter Maxwell wrote:



  I think Bernstein's Salsa20 is faster and significantly more secure than
 RC4, whether you'll be able to design hardware to run at line-speed is
 somewhat more questionable though (would be interested to know if it's
 possible right enough).


 I would be surprised if it is faster.



 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Snowden: Fabricating Digital Keys?

[Natanael]

That depends on the system. Consider how HDCP encryption was broken;

https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection

It used a scheme where access to enough keys allowed you to calculate the
master key, breaking the entire scheme.


2013/6/25 Bill Scannell b...@scannell.org

 This Daily Beast story on Causa Snowden (
 http://www.thedailybeast.com/articles/2013/06/25/greenwald-snowden-s-files-are-out-there-if-anything-happens-to-him.html)
 contains the following sentence:

 Last week NSA Director Keith Alexander told the House Permanent Select
 Committee on Intelligence that Snowden was able to access files inside the
 NSA by fabricating digital keys that gave him access to areas he was not
 allowed to visit as a low-level contractor and systems administrator. 

 How would one fabricate a digital key?


 -Bill
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Potential funding for crypto-related projects

[Natanael]

I'm not seeing that many options though. The Phantom project died pretty
fast;
https://code.google.com/p/phantom/
https://groups.google.com/forum/#!forum/phantom-protocol
http://phantom-anon.blogspot.se/

So who's out there developing any useful protocols for anonymization today?
*Anybody*? Could we try to start a new project (if needed) to create one?
(I would like one with at least the same level of functionality as I2P,
even if it would have to have a very different architecture.)


2013/6/30 Jacob Appelbaum ja...@appelbaum.net

 Natanael:
  I would like to point out that the developers of the anonymizing network
  I2P are looking for more external review of the codebase (it's in Java,
 by
  the way). Everybody who knows how to do security reviews of source code
 and
  has time to spare should take a look at it.
 

 I've previously read papers like this:

   http://grothoff.org/christian/i2p.pdf

 My thought is that some of the ideas behind i2p are interest but many of
 them are... misguided or perhaps ignoring some of the hard won lessons
 from GnuNET, Tor, FreeNet, the Freedom Network, etc.

 We should be reviewing protocols, not the code for i2p, I think. I'm not
 convinced that the overall architecture makes sense from what we know
 about building anonymity systems.

  FYI, I also think that I2P's supernode architecture is a whole lot better
  than Tor's directory servers. It's much more decentralized, to start
 with.
 

 Yeah, about that...

 Have you seen the most recent paper by Egger et al?

 The file is about two weeks old:

   Last-Modified: Fri, 14 Jun 2013 23:46:05 GMT

 Abstract. Anonymity networks, such as Tor or I2P, were built to allow
 users to access network resources without revealing their identity.
 Newer designs, like I2P, run in a completely decentralized fashion,
 while older systems, like Tor, are built around central authorities. The
 decentralized approach has advantages (no trusted central party, better
 scalability), but there are also security risks associated with the use
 of distributed hash tables (DHTs) in this environment.
 I2P was built with these security problems in mind, and the network
 is considered to provide anonymity for all practical purposes. Unfortu-
 nately, this is not entirely justified. In this paper, we present a
 group of attacks that can be used to deanonymize I2P users.
 Specifically, we show that an attacker, with relatively limited
 resources, is able to deanonymize a I2P user that accesses a resource of
 interest with high probability.

 ...

 The developers of I2P have reacted to the publication of attacks, and
 they have improved their network to resist the DHT-based attacks
 introduced in [3] and [4], by limiting the database to a subset of
 well-performing nodes. This reduces the number of nodes involved in each
 individual lookup to only one for most cases. Moreover, the performance
 computation techniques were up-dated to make it more difficult for an
 attacker to exploit them. As a result, I2P
 is considered secure in practice. Unfortunately, this is not entirely
 justified.

 In this paper, we describe an attack that can be used to break the
 anonymity of a victim who is using anonymized resources in I2P – for
 example, a user browsing eepsites (I2P’s terminology for anonymous
 websites) or chatting. We are able, with high probability, to list the
 services the victim accesses regularly, the time of access, and the
 amount of time that is spent using the service

 The full paper is here:

   http://wwwcip.informatik.uni-erlangen.de/~spjsschl/i2p.pdf

 Seems rather... well, not a lot better. :(

  A link on Hidden Services:
  http://donncha.is/2013/05/trawling-tor-hidden-services/
 

 Yeah, Ralf's paper is worth reading:

   http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

 Discussion about this paper starts here - read the thread for tickets,
 fixes, etc:

   https://lists.torproject.org/pipermail/tor-dev/2013-May/004909.html

 All the best,
 Jacob
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Potential funding for crypto-related projects

[Natanael]

Yeah, I know about Tor already of course, but I also want *more options*
(at least so that any critical bugs in one of the options doesn't
automatically put *everybody* at risk), and there's also a few too many
things I don't like about Tor. I know a lot of it can be fixed, but it
would also require a lot of work and time to fix (even if just to make sure
nothing breaks). Such as relatively small keysizes for hidden services
(1024 bit RSA), those short .onion domains (just 80 bits?), some of the
details on how it handles the circuits, etc... I would prefer to see
something new written from scratch, even if it would be based on something
that already exists. At this point, if anonymity is absolutely critical for
you, I don't really trust any of the existing options for much more than
one-off usage like quickly checking something or quickly uploading some
document rather than for live chat (IM or IRC) or continous browsing.

2013/6/30 Jacob Appelbaum ja...@appelbaum.net

 Natanael:
  I'm not seeing that many options though. The Phantom project died pretty
  fast;
  https://code.google.com/p/phantom/
  https://groups.google.com/forum/#!forum/phantom-protocol
  http://phantom-anon.blogspot.se/
 
  So who's out there developing any useful protocols for anonymization
 today?
  *Anybody*? Could we try to start a new project (if needed) to create one?
  (I would like one with at least the same level of functionality as I2P,
  even if it would have to have a very different architecture.)

 I guess you might be interested in this project called Tor? A few of us
 have spent a decade working on it:

   https://www.torproject.org/

 I'd suggest if you want to experiment with Tor and i2p, to try Tails:

   https://tails.boum.org

 All the best,
 Jacob


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Potential funding for crypto-related projects

[Natanael]

Convergence, (in-browser) certificate pinning, and a few more. You could
also use DNSSEC to serve the certificate.


2013/6/30 James A. Donald jam...@echeque.com

 The biggest Tor vulnerability is that governments and large criminal
 organizations (but I repeat myself) can use their influence over a CA to
 perform a man in the middle attack.

 I don't think they are doing this (as I said, they only bother with the
 low hanging fruit) but they could.

 Is there a tool that detects changes of CA?

 __**_
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Paypal phish using EV certificate

[Natanael]

That's trademarks, not copyright, and they get it transfered IF they
request it and the original owner did not have a valid reason to use that
domain with the trademarked name/phrase.

And either way, reusing previously malicious domains for legit purposes is
probably THE WORST method ever of accidentally (?) training users to fall
for scams. Because then you train the user that whatever sign they look for
of it being fake isn't good enough to reject it as a scam, so they are
forced to accept *everything* instead. (Or to stop using the service.)
Den 13 aug 2013 13:21 skrev Tom Ritter t...@ritter.vg:

 On 13 August 2013 07:00, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
  Erwann Abalea eaba...@gmail.com writes:
 
 Looks like paypal-communication.com is a legit domain owned by Paypal,
 Inc.
 
  Even though, according to the second article I referenced, Paypal said
 it was
  a phishing site and said they'd take it down?

 When sites have a phsihing domain that contains their name taken down,
 isn't the domain actually transferred to them, because of copyright?
 Perhaps it went into a domain pool, and someone unaware of its
 provenance reused it.

 -tom
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] urandom vs random

[Natanael]

Most regular people can't accurately test or evaluate the output.
Numbers aren't random, the sources are. You can't just judge a PRNG by
it's output. For all you know the PRNG could be doing nothing more
than doing SHA256 of a fixed value plus a counter, and if somebody
would know that fixed value then bruteforce is trivial since testing a
few thousand counter values isn't all that hard. And yet the output
would *look* random.

2013/8/20 grarpamp grarp...@gmail.com:
 The subject thread is covering a lot about OS implementations
 and RNG various sources. But what are the short list of open
 source tools we should be using to actually test and evaluate
 the resulting number streams?
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Jingle and Otr

[Natanael]

https://jitsi.org/Documentation/ZrtpFAQ

ZRTP and the GNU ZRTP implementation provide features to
communication programs to setup of secure audio and video session
without additional infrastructure, server programs, registration, and
alike.

While this doesn't state outright that Jitsi uses ZRTP for video (it
does for voice), I believe it does. From what I read online, the ZRTP
protocol only uses encryption schemes that have
perfect-forward-secrecy, just like OTR does.

2013/8/21 James A. Donald jam...@echeque.com:
 Jingle supports voice, video, and text messaging.

 OTR is a reasonably user friendly encryption system, or at least less user
 hostile than most, that, unlike skype, does not suffer a central point of
 failure

 pidgin supports both jingle and otr, as well as just about everything else
 in the known universe.

 Is there any convenient way to communicate by video protected by otr?
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Jingle and Otr

[Natanael]

Well, the point here is that ZRTP for video and voice pretty much is
functionally equivalent to OTR for IM. OTR is designed for messages,
ZRTP is designed for data streams.

2013/8/21 James A. Donald jam...@echeque.com:
 On 2013-08-21 12:33 PM, Peter Saint-Andre wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 8/20/13 8:31 PM, Natanael wrote:

 https://jitsi.org/Documentation/ZrtpFAQ

 ZRTP and the GNU ZRTP implementation provide features to
 communication programs to setup of secure audio and video session
 without additional infrastructure, server programs, registration,
 and alike.

 While this doesn't state outright that Jitsi uses ZRTP for video
 (it does for voice), I believe it does.

 Yes, Jitsi uses ZRTP for video.

 The Jitsi FAQ says that chat sessions are protected by OTR, which implies
 that nothing else is.

 In which case, one is better off using skype, where at least only Skype
 central is ratting you out.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Reflection Attacks in Challenge/Response Protocols

[Natanael]

The client and the server shouldn't both generate responses exactly the
same way with the same key, no. If you use HMAC, I think including a simple
identifier would be good enough.  Something like this: HMAC(key, device ID
+ counter + timestamp), where the server and client has different IDs.
Den 24 aug 2013 09:32 skrev Jeffrey Walton noloa...@gmail.com:

 Hi All,

 When a symmetric key based challenge response is used, an attacker can
 perform a reflection attack by starting a second instance of a
 protocol and having the server answer its own questions.

 To guard against the attack, is it sufficient to ensure all challenges
 sent from server to client are equal to 1 mod 2; and all client to
 server challenges are equal to 0 mod 2? Is it enough to break the
 symmetry?

 Jeff
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] no-keyring public

[Natanael]

Bitcoin Brainwallet software creates ECDSA keys that you can use for
multiple purposes, not only for Bitcoin.

A link to Phidelius, which was previously mentioned:
http://dankaminsky.com/2012/01/03/phidelius/

---

I would like to see some standardized hierarchial deterministic scheme
to generate various types of keys from a master password. Here's my
idea for how you could do it in a reasonably secure way (assuming the
master password is chosen in a secure manner and used in a secure
manner);

First of all you have a master password, of course. Ideally it
should be generated randomly (represented to you as words, diceware
style), but arbitary user input is accepted. First you run scrypt (or
bcrypt?) on the master password, salted with a standard string,
generating a master seed.
From this you can generate several different outputs. One of them is
used to generate a number of master keys (RSA, ECDSA, or whatever
else you want) through scrypt with another specific salt from that
master seed. To make sure it's deterministic you use specific
algorithms with predefined parameters. For example ECDSA with the
parameters that Bitcoin uses (we can take this code straight from a
Bitcoin brainwallet generator), or some specific parameters for RSA
4096 bits, or even a specific Lamport scheme implementation. Each
algorithm + parameter combination would be referred to with it's own
specific name.

The master seed is also used to generate a number of temporary seeds
(with scrypt on the master seed plus a special string plus a counter,
and you need to remember this counter once you've started to revoke
and replace old temporary seeds). The temporary seeds are presented to
you encoded as a series of words so you do not need to use your master
password everywhere. They are then used to create a set of temporary
keys in the same way.
You can use your master key(s) to revoke temporary keys. How long you
should use each temporary seed and it's keys is up to you - for
example you could use each for one year, or maybe even just for one
day.

When you enter your master password the client generates a bunch of
these keys and signs the subkeys with the master key(s), allowing you
to publish all those signatures at once, and them memorize the first
temporary seed. It also generates a revocation signature for the
master key(s) themselves that you can publish if/when needed. Then you
can go on using those temporary keys, and be fairly calm about using
the temporary keys as every key is revokable (although revocation
notifications don't always travel fast, which can be a problem...).

Of course this fails catastrophically if you use bad passwords or if
they leak, so I probably would not recommend this for anybody other
than a person who do not have long-term access to any reliable form of
storage, for example a person who are forced to continously ditch
their old electronics and trash it and switch to new temporary
devices.

If you can generate AND remember strong passwords, then it would work
fine. But the problem is that most people fails at one or both of
those two, even though you CAN learn to do it.

2013/8/25 Alexander Klimov alser...@inbox.ru:
 On Sat, 24 Aug 2013, Krisztián Pintér wrote:
 has anybody done something like that already? does it have a name?

 There was a ECC program from the previous century that worked as you
 described: the private key was derived solely from the user password.
 Unfortunately, I cannot recall its name (and I suspect it already
 vanished from the net since it was not secure due to its use of EC
 over binary composite field, Weil descent attack), but I guess someone
 here remembers its name, since at that time it was a rare example of
 ECC software.

 Btw, this memorable private key technique has nothing to do with IBE,
 since no trusted third party is required.

 --
 Regards,
 ASK
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NSA cracking UN videoconference - worried?

[Natanael]

Elsewhere it has been speculated that they got access to the VPN they used.

2013/8/27  pjklau...@gmail.com:
 Dear Cryptographers,

 The article on UN video-conference spying allegations (
 http://america.aljazeera.com/articles/2013/8/25/nsa-bugged-u-n-headquarters.
 html ) claims:

 In the summer of 2012, NSA experts succeeded in getting into the U.N. video
 conferencing system and cracking its coding system, according one of the
 documents cited by Der Spiegel.

 Does anyone know what the coding system, details about the exploit, or
 whether this latest revelation has any cryptographic significance? Or is
 this just a case of breaking through walls and stealing keys in cyberspace.

 - Peter Klauser


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

[Natanael]

Considering that it's designed to not trust the servers in the first
place (just your gateway, which often will be part of your own client
or otherwise run locally), it's not all too hard. If you've verified
the client, then you can be sure your data is secure.

2013/8/29 Nikos Fotiou niko...@gmail.com:
 A naive comment.

 In his first email Zooko states:

 S4 offers “*verifiable* end-to-end security” because all of the source
 code that makes up the Simple Secure Storage Service is published for
 everyone to see

 A suspicious user may wonder, how can he be sure that the service
 indeed uses the provided source code. IMHO, end-to-end security can be
 really verifiable--from the user perspective--if it can be attested by
 examining only the source code of the applications running on the user
 side.

 Best,
 Nikos

 On Sat, Aug 17, 2013 at 11:52 AM, ianG i...@iang.org wrote:
 On 16/08/13 22:11 PM, zooko wrote:

 On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote:


 Nothing really gets anyone past the enormous supply of zero-day vulns in
 their complete stacks.  In the end I assume there's no technological PRISM
 workarounds.


 I agree that compromise of the client is relevant. My current belief is
 that
 nobody is doing this on a mass scale, pwning entire populations at once,
 and
 that if they do, we will find out about it.

 My goal with the S4 product is not primarily to help people who are being
 targeted by their enemies, but to increase the cost of indiscriminately
 surveilling entire populations.

 Now maybe it was a mistake to label it as PRISM-Proof in our press
 release
 and media interviews! I said that because to me PRISM means mass
 surveillance
 of innocents. Perhaps to other people it doesn't mean that. Oops!



 My understanding of PRISM is that it is a voluntary  secret arrangement
 between the supplier and the collector (NSA) to provide direct access to all
 information.

 By 'voluntary' I mean that the supplier hands over the access, it isn't
 taken in an espionage or hacker sense, or leaked by an insider.  I include
 in this various techniques of court-inspired voluntarianism as suggested by
 recent FISA theories [0].

 I suspect it is fair to say that something is PRISM-proof if:

   a) the system lacks the capability to provide access
   b) the operator lacks the capacity to enter into the voluntary
 arrangement, or
   c) the operator lacks the capacity to keep the arrangement (b) secret

 The principle here seems to be that if the information is encrypted on the
 server side without the keys being held or accessible by the supplier, then
 (a) is met [1].

 Encryption-sans-keys is an approach that is championed by Tahoe-LAFS and
 Silent Circle.  Therefore I think it is reasonable in a marketing sense to
 claim it is PRISM-proof, as long as that claim is explained in more detail
 for those who wish to research.

 In this context, one must market ones product, and one must use simple
 labels to achieve this.  Otherwise the product doesn't get out there, and
 nobody is benefited.



 iang


 [0] E.g., the lavabit supplier can be considered to have not volunteered the
 info, and google can be considered to have not volunteered to the Chinese
 government.
 [1]  In contrast, if an operator is offshore it would meet (b) and if an
 operator was some sort of open source distributed org where everyone saw
 where the traffic headed, it would lack (c).





 Regards,

 Zooko

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Asynchronous forward secrecy encryption

[Natanael]

I made a suggestion like this elsewhere:

Store the keys split up in several different files using Shamir's Secret
Sharing Scheme. Encrypt each file with a different key. Encrypt those keys
with a master key. XOR each encrypted key with the SHA256 of their
respective encrypted files. Put those XORed keys in the headers of their
respective files.

If you manage to securely wipe just ~100 bits of any of the files, the keys
are unrecoverable.

I don't know if that can provide enough assurance of secure deletion on a
flash memory, but it's better than nothing.
Den 23 sep 2013 14:40 skrev Michael Rogers mich...@briarproject.org:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 23/09/13 05:12, Dev Random wrote:
  I've been thinking about this for a while now and I don't see a way
  to do this with today's mobile devices without some external help.
 
  The issue is that it's pretty much impossible to delete data
  securely from a flash device.  That means that in order to
  guarantee PFS, you have to store the keys in memory only.  But
  again, in a mobile environment, you don't have access to stable
  memory either, because of the OS restarting your app, or the device
  itself rebooting.
 
  Let's call this the persistence/deletion issue.

 Yes, this is a major issue with current mobile devices. As far as I'm
 aware, SSD commands like Trim and Secure Erase aren't available on SD
 cards or the built-in flash storage of mobile devices.

 Apple came within a whisker of solving the problem in iOS by creating
 an 'effaceable storage' area within the flash storage, which bypasses
 block remapping and can be deleted securely. However, iOS only uses
 the effaceable storage for resetting the entire device (by deleting
 the key that encrypts the user's filesystem), not for securely
 deleting individual files.


 http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf


 http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf

 A similar approach would be possible on Android, but I don't know of
 any Android devices with effaceable storage. The closest I've seen is
 hardware-backed key storage, where keys are generated, wrapped and
 deleted by a TPM-like chip. Software can use the TPM to perform
 operations using the wrapped keys but can't directly access them, and
 thus they can't be exported from the device without cracking open the
 TPM (physically or via a vulnerability).


 http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html

 In combination with a hardware-based flash controller, this raises the
 bar for undeleting data pretty high: the adversary must compromise the
 flash controller to get access to data that's been logically but not
 physically deleted, then compromise the TPM to unwrap or undelete the
 deleted key with which the deleted data was encrypted.

 I'm not saying the bar is too high for a national security agency, but
 it's too high for some adversaries, so I believe it's worthwhile to
 think about forward secrecy on current mobile devices.

  So, I submit that PFS in async messaging is impossible without help
  from some kind of ephemeral, yet persistent storage.  A possible
  solution might be to store a portion of the key material (through
  Shamir's secret sharing) on servers that you partially trust.

 Sounds like a great idea, especially in combination with a panic
 button or dead man's switch feature that alerts the servers to delete
 their shares.

 Cheers,
 Michael

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k
 qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S
 w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O
 OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ
 eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53
 UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk=
 =G1oY
 -END PGP SIGNATURE-
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Unbreakable Cipher

[Natanael]

For your question: Session keys and key rotation?
Den 25 sep 2013 16:11 skrev John Young j...@pipeline.com:

  NSA Technical Journal published The Unbreakable Cipher in Spring 1961.

 http://www.nsa.gov/public_info/_files/tech_journals/The_Unbreakable_Cipher.pdf

 Excerpts:

 [Quote]

 David Kahn, Lyen Otuu Wllwgh WI Etjown pp. 71, 83, 84, 86,
 88 and 90 of the *New York Times Magazine *November 13, 1960
 says that an unbreakable cipher system can be made from one
 time key that is absolutely random and never repeats.  ...

 For each cipher system there is an upper bound to the amount of
 traffic it can protect against cryptanalytic attack. What is
 cryptanalytic attack? It is a process applied to cipher text
 in order to extract information, especially information
 contained in the messages and intended to be kept secret.
 If some of the information is gotten by other means and this
 results in more being extracted from the cipher, this is (at
 least partially) a successful attack. If certain phrases can be
 recognized when they are present, this is successful cryptanalysis.
 If a priori probabilities on possible contents are altered by
 examination of the cipher, this is cryptanalytic progress.
 If in making trial decipherments it is possible to pick out
 the correct one then cryptanalysis is successful. ...

 Another example is that of Mr. Kahn, one-time key. Here the
 limit is quite clear; it is the amount of key on hand. The key arrives
 in finite messages, so there is only a finite amount on hand at
 anyone time, and this limits the amount of traffic which can be sent
 securely. Of course another shipment of key raises this bound, but
 technically another cipher system is now in effect, for by my
 definition a cipher system is a message. A sequence of messages
 is a sequence of cipher systems, related perhaps, but not the same. ...

 [Answer to the question:] Does there exist an unbreakable cipher
 would be this, Every cipher is breakable, given enough traffic, and
 every cipher is unbreakable, if the traffic volume is restricted
 enough.

 [End quote]

 Is this conclusion still valid? If so, what could be done to restrict
 traffic
 volume to assure unbreakablility? And how to sufficiently test that.
 Presuming that NSA and cohorts have investigated this effect.

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[Natanael]

Carrier-agnostic encrypted mesh routing software: CJDNS.

Cantenna, IR-link based RONJA, ethernet/LAN, whatever. If you've got a
data link you can use it.

It creates an IPv6 network internally in the 'fc' range (private
network) where the address is a hash of the node's public key.

On Wed, Sep 25, 2013 at 10:07 PM, John Young j...@pipeline.com wrote:
 Now that it appears the Internet is compromised what other
 means can rapidly deliver tiny fragments of an encrypted
 message, each unique for transmission, then reassembled
 upon receipt, kind of like packets but much smaller and less
 predictable, dare say random?

 The legacy transceiver technologies prior to the Internet or
 developed parallel to it, burst via radio, microwave, EM emanations,
 laser, ELF, moon or planetary bounce, spread spectrum, ELF,
 hydro, olfactory, quanta, and the like.

 Presumably if these are possible they will remain classified, kept
 in research labs for advanced study, or shelved for future use.

 Quite a few are hinted at, redacted and partially described in
 NSA technical publications from 25-50 or so years ago. Many
 developed for military use and the best never shared with the
 public.

 A skeptic might suppose the internet was invented and promoted as
 a diversion along with public-use digital cryptography. This ruse
 has led to immense growth in transmission-breakable ciphers
 as well as vulnerable transceivers. Packet techology could hardly
 be surpased for tappability as Snowden and cohorts disclose the
 tip of the iceberg. Ironically, the cohorts believe encryption protects
 their communications, conceals his location and cloaks the
 depositories.



 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] One Time Pad Cryptanalysis

[Natanael]

That would be known plaintext attack (or statistical analysis like how
simple ciphers typically are broken) vs chosen plaintext attack (BREACH is
the latter, while compression would increase entropy density to make the
former harder since each individual bit becomes harder to predict).

Sorry, no sources from me either. I could try looking for some.

- Sent from my phone
Den 2 okt 2013 19:38 skrev danimoth danim...@cryptolab.net:

 On 02/10/13 at 08:51am, Florian Weimer wrote:
  There is widespread belief that compressing before encrypting makes
  cryptanalysis harder, so compression is assumed to be beneficial.


 Any academic references?

 Without these, IMHO your sentence is false.

 Example: http://breachattack.com/
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] ciphersuite revocation model? (Re: the spell is broken)

[Natanael]

Should we create some kind of CRL style protocol for algorithms? Then we'd
have a bunch of servers run by various organizations specialized on
crypto/computer security that can issue warnings against unsecure
algorithms, as well as cipher modes and combinations of ciphers and
whatever else it might be. And your client software would subscribe to a
bunch of those servers.

There should probably be degrees to the warnings, since a cipher can be
totally broken in one set of circumstances but still work perfectly fine in
others. Switching when its not needed can be costly.

I think I'd prefer if this was OS level and all your local software could
use it.

I think a problem can be that there doesn't seem to be a universal naming
convention for ciphers or ciphersuites in software configurations. We'd
have to define one that clients can understand.

- Sent from my phone
Den 5 okt 2013 13:41 skrev Adam Back a...@cypherspace.org:

 You know part of this problem is the inability to disable dud
 ciphersuites. Maybe its time to get pre-emptive on that issue: pair a
 protocol revocation
 cert with a new ciphersuite.

 I am reminded of mondex security model: it was a offline respendable
 smart-card based ecash system in the UK, with backing of a few large name
 UK
 banks and card issuers, with little wallets like calculators to check a
 cards balance.  Secure up to tamper resistance or ciphersuite cryptographic
 break.  Not sure mondex got very far in market penetration beyond a few
 trial runs, but the ciphersuite update model is interesting.

 So their plan was deploy ciphersuite A, and B in the first card issue.  Now
 when someone finds a defect in ciphersuite A, issue a revocation cert for
 ciphersuite A, and deploy it together with a signed update for ciphersuite
 C, that you work on polishing in the background during the life-cycle of
 A. Then the cards run on ciphersuite B, with C as the backup.  At all times
 there is a backup, and at no time do you run on known defective
 ciphersuites.

 Now the ciphersuite revocation certs are distributed actually p2p because
 mondex is offline respendable.  If a card encounters another card that has
 heard the news that ciphersuite A is dead, it refuses to use it, and passes
 on the signed news.

 Maybe to get the update they actually have to go online proper, after a
 grace period of running only on ciphersuite B, but thats ok, it'll only
 happen once in a few years.  Ciphersuite A is pretty instantly disabled as
 the news spreads with each payment.
 Maybe something like that could work for browser ciphersuites.
 It something related to vendor security updates, except there is a
 prompting
 that each site and client you interact with starts warning you the clock is
 ticking that you have to disable a ciphersuite.  If you persist to ignore
 it
 your browser or server stops working after 6months.
 Adam

 On Sat, Oct 05, 2013 at 02:03:38PM +0300, ianG wrote:

 On 4/10/13 10:52 AM, Peter Gutmann wrote:

 Jon Callas j...@callas.org writes:

  In Silent Text, we went far more to the one true ciphersuite
 philosophy. I
 think that Iang's writings on that are brilliant.


 Absolutely.  The one downside is that you then need to decide what the
 OTS is
 going to be.  For example Mozilla (at least via Firefox) seems to think
 it
 involves Camellia (!!!?!!?).



 Thanks for those kind words, all.  Perhaps some deeper background.

 When I was writing those hypotheses, I was very conscious that there was
 *no silver bullet*.  I was trying to extrapolate what we should do in a
 messy world?

 We all know that too many ciphersuites is a mess.  We also know that only
 one suite is vulnerable to catastrophic failure, and two or three suites is
 vulnerable to downgrade attacks, bugs in the switching, and expansion
 attacks in committee.

 A conundrum!

 Perhaps worse, we know that /our work is probably good/ but we are too
 few!  We need ways to make cryptoplumbing safe for general software
 engineers, not just us.  Not just hand out received wisdom like use TLS
 or follow NIST.  If we've learnt anything recently, it is that standards
 and NISTs and similar are not always or necessarily the answer.

 There are many bad paths.  I was trying to figure out what the best path
 among those bad paths was.  From theory, I heard no clarity, I saw noise.

 But in history I found clues, and that is what informs those hypotheses.



 If one looks at the lifecycle of suites (or algorithms, or protocols, or
 products) then one sees that typically, stuff sticks around much longer
 than we want.  Suites live way past their sell-by date.  Once a
 cryptosystem is in there, it is there to stay until way past embarrassing.
  Old, algorithms, old suites are like senile great-aunts, they hang around,
 part of the family, we can't quite see how to push them off, and we justify
 keeping her for all sorts of inane reasons.

 Alternatively, if one looks at the history of failures, as John Kelsey
 pointed to a few 

Re: [cryptography] coderman's keys

[Natanael]

No hints at what kind of client it takes? Custom config or recompile?

- Sent from my phone
Den 1 nov 2013 05:11 skrev coderman coder...@gmail.com:

 On Thu, Oct 31, 2013 at 7:55 PM, coderman coder...@gmail.com wrote:
  my contempt for email is well known and reinforced by choice of provider.
 
  there are myriad rebuttals to email as private channel, of which i
  agree fully.  however, if you pass muster, i can be reached via secure
  email.  yes your default client will balk.  this is a feature not a
  bug...  you must be this high to ride...


 still no successful encrypted responses.  do i have to sweeten this pot?

 let's try an experiment: one bitcoin (~200$USD) to whoever
 successfully encrypts a message to my key.

 ... ready, set, go!
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bitcoin attack

[Natanael]

Can't the distributed pool P2Pool easily be updated to account for that?

- Sent from my phone
Den 4 nov 2013 16:33 skrev Peter Todd p...@petertodd.org:

 On Mon, Nov 04, 2013 at 09:31:04AM -0430, Karn Kallio wrote:
 
  The paper Majority is not Enough Bitcoin Mining is Vulnerable may be of
  interest.
 
 
  http://arxiv.org/abs/1311.0243
 
  Abstract. The Bitcoin cryptocurrency records its transactions in a pub-
  lic log called the blockchain. Its security rests critically on the
  distributed
  protocol that maintains the blockchain, run by participants called
 miners.
  Conventional wisdom asserts that the protocol is incentive-compatible
  and secure against colluding minority groups, i.e., it incentivizes
 miners
  to follow the protocol as prescribed.
  We show that the Bitcoin protocol is not incentive-compatible. We
  present an attack with which colluding miners obtain a revenue larger
  than their fair share. This attack can have significant consequences for
  Bitcoin: Rational miners will prefer to join the selfish miners, and the
  colluding group will increase in size until it becomes a majority. At
 this
  point, the Bitcoin system ceases to be a decentralized currency.
  Selfish mining is feasible for any group size of colluding miners. We
 pro-
  pose a practical modification to the Bitcoin protocol that protects
 against
  selfish mining pools that command less than 1/4 of the resources. This
  threshold is lower than the wrongly assumed 1/2 bound, but better than
  the current reality where a group of any size can compromise the system.

 I replied on the bitcoin-development email list with what I believe is a
 better solution than presented in the paper. In particular my solution
 returns the attack threshold to 51%, rather than the 25% they achieve:


 Remember that the selfish miner strategy outlined in the paper is
 essentially a way to use knowledge of what blocks miners will be mining
 on, from the first seen rule, and the ability to broadcast blocks you
 have mined more widely than other miners. That knowledge and ability is
 then used in conjunction with a small lead (obtainable by chance) to
 outpace the rest of the network.

 By making all miners easily identifiable you make gaining that
 informational and broadcast capability easier to obtain rather than
 harder. The attacker now only needs to connect to every identified miner
 with especially fast nodes. With judicious use of DoS attacks and low
 latency they can still gain the informational and broadcast upper hand
 over other miners and carry out the attack.

 Where the paper goes wrong is they don't recognize the fundemental
 nature of the strategy being based on an informational advantage. Their
 pick a random side of the fork strategy may work to some extent, but
 it's incomplete and isn't necessarily rational for the miners
 individually.

 The correct, and rational, approach for a miner is to always mine to
 extend the block that the majority of hashing power is trying to extend.
 The current relay rules don't give you that information at all, but they
 can if we do two things:

 1) Relay all blocks that meet the PoW target. (as suggested in the
paper)

 2) Relay block headers that nearly meet the PoW target.

 Mining strategy is now to mine to extend the first block you see, on the
 assumption that the earlier one probably propagated to a large portion
 of the total hashing power. But as you receive near-blocks that are
 under the PoW target, use them to estimate the hashing power on each
 fork, and if it looks like you are not on the majority side, switch.

 This very effectively defeats the paper's selfish-miner strategy, as all
 miners will very quickly be mining on the block that truly has the
 majority of hashing power trying to extend it. This is also a better
 overall outcome, because it puts the 51% attack threshhold back at 51%


 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03137.html

 --
 'peter'[:-1]@petertodd.org
 0002229a07d0a264dd3f687d3d93d6eb14f26205d5dab8db5afa

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [tahoe-dev] SNARKs, constant-time proofs of computation

[Natanael]

SCIPR is another one. http://www.scipr-lab.org/

If it became efficient it could be useful for mining in a Bitcoin fork
(commonly called altcoins). Don't know what kind of computations you'd
actually would want it to do, though. Most meaningful computations could
easily be deprecated by better algorithms, forcing you to switch algorithms
often. You also have the problem of achieving consensus for what to
compute.

What exactly would it be used for in Tahoe-LAFS?

- Sent from my phone
Den 7 nov 2013 18:54 skrev Steve Weis stevew...@gmail.com:

 Hi Andrew. You may be interested in contacting an early-phase startup
 called Tegos:
 http://www.tegostech.com/

 They're in stealth mode and haven't posted any info online, but they are
 legitimate and relevant to this work.

 On Thu, Nov 7, 2013 at 8:39 AM, Andrew Miller amil...@cs.ucf.edu wrote:

 Here's a possible Tesla Coils and Corpses discussion I'd like to have
 sometime a few weeks from now maybe:
SNARKs (Succinct Non-interactive Arguments of Knowledge) are a
 recent hot topic in modern cryptography. A generic SNARK scheme lets
 you can take an arbitrary computation (e.g., the routine that checks a
 signature and a merkle tree branch) and compile it to a *constant
 size* compressed representation, called the verification key. An
 untrusted server can execute the computation on behalf of the client,
 and produce a *constant size* proof that it was carried out correctly.


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NIST Randomness Beacon

[Natanael]

Proof-of-work, just like Bitcoin itself uses for hashing? See hashcash as
well. Require that the message in question is hashed together with a random
value, with an output that matches a given pattern. And specify that one
part of the message has to be the hash of a Bitcoin block from the given
time period.

- Sent from my phone
Den 11 nov 2013 17:43 skrev CodesInChaos codesinch...@gmail.com:

 On Sun, Nov 10, 2013 at 9:54 AM, Andy Isaacson a...@hexapodia.org wrote:
  For example, suppose you use the low bits of the bitcoin blockchain
  hash.  An attacker with 10% of the hash power could probabilistically
  attack such a system by chosing blocks with a specific value in those
  bits;

 This can be avoided by running a sequential computation based on that
 hash. For example
 by hashing it 2^40 times. Obvious downside is that verifying that the
 computation was performed
 correctly is just as expensive (but parallelizable).

 Perhaps there is a function that's sequential and slow in one
 direction and fast in the reverse direction.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NIST Randomness Beacon (andrew cooke) (and Andy Isaacson, et al.)

[Natanael]

Because there's no guarantees at all for anything at all for that site.

On Wed, Nov 13, 2013 at 6:10 PM, Joshua Kingsolver Price
jprice...@ivytech.edu wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Something of a noob question, but what about random.org? Is there some
 reason why this site isn't used by the cryptographically wise? It
 seems that they already offer public entropy, and from a very good
 source. Sure you still can't use it for keys, but you couldn't use ANY
 public source for that, so what's the difference?

 Message: 1 Date: Sun, 10 Nov 2013 05:15:33 -0300 From: andrew
 cooke and...@acooke.org To: d.nix d@comcast.net Cc:
 cypherpu...@cpunks.org, cryptogra...@metzdowd.com,
 cryptography@randombit.net cryptography@randombit.net Subject:
 Re: [cryptography] NIST Randomness Beacon Message-ID:
 20131110081533.gh24...@acooke.org Content-Type: text/plain;
 charset=us-ascii


 the idea of a service that provides data unknown before a certain
 date (like a photo of a recent newspaper) was suggested here -
 http://rachelbythebay.com/w/2012/08/29/info/

 for fun, i implemented that here - http://colorlessgreen.net/ (the
 random value is updated every 5 secs, roughly, and encoded as
 a memorable phrase)

 of course, in this case, a PRNG was used, and i am not NIST (so i
 am not guaranteeing unpredictability ot autonomy to the same
 extent!), and the output is only ~50 bits in size.

 as far as i know, no-one uses it for anything...

 andrew


 On Sat, Nov 09, 2013 at 08:28:17PM -0800, d.nix wrote:

 surely someone here has an opinion...

 http://www.nist.gov/itl/csd/ct/nist_beacon.cfm

 :-)


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBAgAGBQJSg7KdAAoJEBt4bfGB1f9U770QAKaizwlAU1em/xtcjiJEPycs
 pP+4suRMEf4xJyk5jR4sEBoWdTK9RsE0kaEgvXZ/3MkNTLoVBs8MxEhDh7z/QhW6
 VWtY29ZH4KAoXfozTMQ0cw1hpA3b5Pab3CcmcpDOYXo6v1um0tDkal8jrLSpDN11
 Prn+tUjC+uGeGnLJOizDpQgefDLYhm4GmcJT+g2kxbsYJ1D4pv6wWWNV596dcIvo
 ScLOefQZr2ELTkCuqPzunKNAP00WCKXvBLB1YcsePaHtmFaIWJIr1Ul6R0ottmqz
 8Z3PCEH2/soi9D55uKDWX85TDjB9u/VU8fnbQYvfrz0eY/K1SSSRMnbF5KDBpAis
 DAC9P3xFS322A+Jt3GgVeTP5BMsNdM1E1Q0Z+yrC+AJu3ONe8smSh/cXBzLZ5RCE
 XVROV8fVJ9JORrdr+oz8YdpqEePsqf9vTVaHz+GW2RnsUi15rtHfyFLt4vm0zA44
 G+eivxbV7eIn27AEm1dMi6Ko/GGZsZumAQkm1DWsIyWmodDggJVOckrH+2litu3F
 dUi/ok1xlDV5qvOhTkMOBD53fHfsh0J0BT0Ec5WXx2RQR/7H2KK8bk6rYLCaYQzW
 Q1rI+a6jfj8CQz6a/Cen16OK7IMByQDpZ1J28v65Fu7lDkm3gVuJp8MvHsaNbHJo
 uO1AKyRSJf5geqdLw3ob
 =hS8R
 -END PGP SIGNATURE-
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Natanael]

Say hello to Bote mail on I2P.

I2P provides encrypted anonymizing networking, Bote mail provides DHT based
serverless encrypted mailing with public crypto keys as addresses (ECDSA or
NTRU).

http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to
visit it via an inproxy).

There is also I2P Messenger that is encrypted P2P IM within I2P also using
public keys as addresses.

- Sent from my phone
Den 25 nov 2013 19:15 skrev grarpamp grarp...@gmail.com:

 On Mon, Nov 25, 2013 at 1:01 AM, ianG i...@iang.org wrote:
  On 23/11/13 15:30 PM, Ralf Senderek wrote:
  On Sat, 23 Nov 2013, David Mercer wrote:
 
  But of course you're right about actual current usage, encrypted email
  is an
  epic fail on that measure regardless of format/protocol.
 
  Yes, but it's about time we do something about that. Do we *exactly know
  why* it is such a failure?
 
  It's an interesting question, and one worth studying for pedagogical
  motives.  From my experiences from both sides, it is clear that both
 sides
  failed.  But for different reasons.
  Hence, I've concluded that email is unsecurable.

 Obviously. It will never be able to escape the non-body
 header content and third party routing, storage and analysis with
 any form of patching over today's mail. And it's completely
 ridiculous that people continue to invest [aka: waste] effort in
 'securing' it. The best you'll ever get clients down to is exposing
 a single 'To:' header within an antique transport model that
 forces you to authenticate to it in order to despam, bill, censor
 and control you.

 That system is cooked, done and properly fucked. Abandon it.
 What the world needs now is a real peer to peer messaging
 system that scales. Take Tor for a partial example... so long
 as all the sender/recipient nodes [onions] are up, any message
 you send will get through, encrypted, in real time. If a recipient
 is not up, you queue it locally till they are... no third party ever
 needed, and you get lossless delivery and confirmation for free.
 Unmemorable node address?, quit crying and make use of your
 local address book. Doesn't have plugins for current clients?,
 so what, write some and use it if you're dumb enough to mix
 the old and new mail.

 The only real problem that still needs solved is scalability...
 what p2p node lookup systems are out there that will handle
 a messaging world's population worth of nodes [billions] and
 their keys and tertiary data? If you can do that, you should
 be able to get some anon transport over the p2p for free.

 Anyway, p2p messaging and anonymous transports have
 all been dreamed up by others before. But now is the
 time to actually abandon traditional email and just do it.
 If you build it, they will come.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Natanael]

And there's your problem - you can at best only add gateways/proxies, you
can't actually improve the existing protocols in any meaningful way.

- Sent from my phone
Den 25 nov 2013 21:09 skrev Fabio Pietrosanti (naif) 
li...@infosecurity.ch:

 I'm strongly against most the ideas to abbandon current email systems,
 because the results will be to create wallet garden.

 We need something interoperable with existing systems or the system will
 just be used by a bunch of paranoid people or fostered by the marketing
 of few cryptography company acquiring customers, not user.

 So we need IETF standards, interoperable with existing email standard
 protocols (SMTP, IMAP, MIME).

 I'm just very disappointed that many of us look at the moon, trying to
 invent something new, when there are so many improvements to be done on
 existing interoperable platforms.

 Let's first cut-off the massive passive traffic analysis, then improve
 current systems to provide some added protection against metadata,
 focusing in a far future, when the new system got already wide adoption,
 make it perfect.

 Fabio

 Il 11/25/13, 7:20 PM, Natanael ha scritto:
 
  Say hello to Bote mail on I2P.
 
  I2P provides encrypted anonymizing networking, Bote mail provides DHT
  based serverless encrypted mailing with public crypto keys as
  addresses (ECDSA or NTRU).
 
  http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add
  .us to visit it via an inproxy).
 
  There is also I2P Messenger that is encrypted P2P IM within I2P also
  using public keys as addresses.
 

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Natanael]

That can really only be solved by gateways, IMHO. It's the only way to talk
between the systems that don't put limits on how secure either one can be.

- Sent from my phone
Den 26 nov 2013 16:09 skrev c1cc10 r...@isolved.it:

 If we're discussing about this topic it is because of people. emails are
 one people's need: as techis we could create and use any other fancy
 communication means and do not bother.
 So if we want to bring a new communication infrastructure for everybody
 we cannot jump over the existing one, which sadly is the unsecurable email.
 Thus we need to consider back-compatibility for any upgrade of the email
 protocol, in order to let anyone use it as they do it now.

 my 2 cents

 Francesco Rana
  On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell
  stephen.farr...@cs.tcd.ie wrote:
  ...
  Personally, I'm not at all confident that we can do something
  that provides end-to-end security, can be deployed at full
  Internet scale and is compatible with today's email protocols.
  But if others are more optimistic then I'm all for 'em trying
  to figure it out and would be delighted to be proven wrong.
 

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email is unsecurable

[Natanael]

Bote mail doesn't have to be used for it's anonymous properties, for me
that is just a bonus. For many people it is more than enough to be able to
know that it is impossible for anybody else than the intended recipient to
read the message thanks to public key addressing. Guaranteed end-to-end
security if you can verify the address.

I don't think anything that doesn't fundamentally rely on public key
addressing is the (long term) future. There will inevitably issues
otherwise, including more issues of the type we have with CA:s today.

For those who want to make it more user friendly, nothing stops you from
adding a transparent address translation layer where servers are
involved. When you want to send a message to a person with a human readable
address at a server, then the server could then reply with the public key
based address to the mail client, and the user would have the option to see
what that address is. It could even be logged by the client, with TOFU/POP
style trust system that reduces the amount of trust you have to place in
the server. No need to trust anybody with plaintext.

- Sent from my phone
Den 26 nov 2013 21:58 skrev pjklau...@gmail.com:


 From: Stephen Farrell stephen.farr...@cs.tcd.ie
 To: Fabio Pietrosanti (naif) li...@infosecurity.ch,
 cryptography@randombit.net
 Message-ID: 5293c66d.4040...@cs.tcd.ie
 
  On 11/25/2013 08:09 PM, Fabio Pietrosanti (naif) wrote:
   Let's first cut-off the massive passive traffic analysis, then improve
   current systems to provide some added protection against metadata,
   focusing in a far future, when the new system got already wide
   adoption, make it perfect.
 
  New work on improving hop-by-hop security for email and other things is
  getting underway in the IETF. [1] Basically the idea is to document stuff
  that can be turned on already in current deployments (to the extent
  possible) that gets you PFS and modern TLS ciphersuites.
 Pre-working-group
  charter discussion for this is being directed to the
 apps-disc...@ietf.org
  list for now, or if folks aren't keen to get on that list, feel free to
  send me comments and I'll make sure they get into the pot. I'll send a
  mail here when the WG is officially kicked off (in a few weeks hopefully)
  with a pointer to the eventual wg mailing list.

 way to go!
 Personally I don't see how using a P2P network in any next-gen email system
 helps anything. If I send a message to someone, I trust my service provider
 to deliver the message to the recipients service provider. If the
 communication path is limited to this minimum 3 hops - and each hop is
 secure, then this could be good enough ( considering each service
 provider
 can be sure that it's talking with the other one directly and securely ).
 This is the system architecture proposed for TDMX[2] for a new
 transactional
 enterprise messaging (yet-to-be standard) system I'm working on. Between
 each hop is anyway an anonymous void of untrustworthyness - called the
 internet ( adding any application layer complexity seems overkill ).

 If you don't ( and you probably can't ) trust your service provider
 (enough)
 then there's nothing stopping you running your own.

 Furthermore, Email doesn't need anonymization ( it got to where it is today
 without it - it will survive some more) and in fact I argue in [1] that
 corporations cannot really use use end-to-end security either.

 [1]

 http://pjklauser.wordpress.com/2013/11/17/why-enterprises-wont-embrace-darkm
 ail/
 [2] http://tdmx.org



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Natanael]

So, Convergence/Perspectives done on email headers?

- Sent from my phone
Den 27 nov 2013 22:07 skrev Stephen Farrell stephen.farr...@cs.tcd.ie:



 On 11/27/2013 09:01 PM, Jeffrey Walton wrote:
  Isn't the key distribution problem being pushed into DNS? The
  underlying problem still exists.

 Depends. If say someone ended up sampling the mail header
 field values seen over a lot of messages then exceptions
 to key continuity for mail service providers would perhaps
 be enough to flag potential MITM attacks on the TLS
 sessions, or odd MTAs popping up from nowhere, which are
 at least some of the goals here.

 So DKIM-level security could actually be quite useful in
 this case I reckon.

 S.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement

[Natanael]

Sounds just like the Bitcoin blockchain to me. Or maybe the fork Namecoin.

- Sent from my phone
Den 18 dec 2013 02:20 skrev James A. Donald jam...@echeque.com:

 On 2013-12-18 04:38, Joseph Birr-Pixton wrote:

 In very general terms, you cannot hope to achieve confidentiality
 without authenticity.

 Your key exchange does not offer authenticity. I would suggest instead
 having the user's keys be signing keys, and do straightforward signed
 ephemeral ECDH. This should also gain you forward secrecy.
 Unfortunately this will introduce a data dependency in your protocol,
 which may cause an unacceptable extra round trip.

 With that assumed fixed, your protocol relies entirely on a third
 party (the 'public key server') for authenticity of the key exchange.
 If the overall aim is to avoid having to trust a third party
 (Facebook) to keep messages secret, adding more third parties to the
 problem doesn't seem a great solution.


 Google solution:  Implement a protocol such that the key server cannot
 tell the owner of the name on thing, and someone else trying to contact the
 owner of the name a different thing, and cannot rewrite the past.

 Bittorrent serves immutable files globally, such that the file must be the
 same for all.  Need a bittorent like algorithm for serving slowly mutable
 tree structures.  Viewed as a history, it is a grow only data structure
 with an ever increasing immutable past.  The history, however, is kind of
 like a git history, representing a fully mutable but slowly changing
 present.
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Mixing RdRand with other CPU-based entropy sources?

[Natanael]

It's always a good idea to use several entropy sources and
cryptographically mix their outputs into your pool. They won't reduce your
total entropy either way, any predictable sources will only be adding less
entropy than promised.

- Sent from my phone
Den 19 dec 2013 09:19 skrev Joachim Strömbergson joac...@strombergson.com
:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Aloha!

 Here is a question: If we (barely) trust RdRand enough to use it as an
 entropy source in combination with another source to feed our RNG -
 would it be wise to use another CPU-based entropy source such ad Haveged
 [1], DakaRand [2], Jytter [3] or the CPU Jitter Random Number Generator
 [3] by Stephan Müller? Or should the second one alway be a CPU-external
 source?

 A tengential question - is running these entropy sources ([1]..[2]) in
 parallel a good idea?


 [1] http://www.issihosts.com/haveged/
 [2] http://dankaminsky.com/2012/08/15/dakarand/
 [3] http://jytter.blogspot.se/
 [4] http://www.chronox.de/

 - --
 Med vänlig hälsning, Yours

 Joachim Strömbergson - Alltid i harmonisk svängning.
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlKyq/cACgkQZoPr8HT30QGALACeJhV2LbPEpMHQQl0GteZEVNmq
 kVYAn3YGrGKTgUgzUSlB8exFvbCMJDI3
 =qTBy
 -END PGP SIGNATURE-
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DNSNMC replaces Certificate Authorities with Namecoin and fixes HTTPS security

[Natanael]

That sounds a lot like my Web of Trust based DNS suggestion. Link:

http://www.reddit.com/r/Meshnet/comments/o3wex/wotdns_web_of_trust_based_domain_name_system

Domain names would not be globally unique, where they go would instead be
based on each individual node's trust ranking for the site's node and for
the nodes that has signed a vote for that domain name association.
Communities could set a high level of trust to the same set of trusted
people to make sure domain names used within the community goes to the same
place for all the members.

- Sent from my phone
Den 22 dec 2013 10:45 skrev Marcus Brinkmann 
marcus.brinkm...@ruhr-uni-bochum.de:

 On 12/21/2013 10:04 PM, Eduardo Robles Elvira wrote:

 The obvious problem with this is that namecoin doesn't have all the
 domain names already registered assigned to the current owners, and
 there's no arbitration authority that can prevent domain cibersquatting.


 This is not a weakness of namecoin, but a weakness of human readable names.

 Why does coke.ch lead to the website of the Coca Cola Company, and not an
 informational website on heroin addiction?  Because someone at that company
 decided to cibersquat this domain.

  So I can register all the important domains: microsoft, ebay, google,
 nsa, whitehouse,


 They are only important if you value e-commerce, advertising and the US
 institutions more than the alternatives that could exist.

 The solution to this is that names should not claimed, they should be
 given by the community that values the association.  Neither DNS nor
 namecoin allows for that, so both are inadequate.  As an example, consider
 how Wikipedia pages are named: http://en.wikipedia.org/wiki/Coke

 This is painfully obvious, and yet we are mentally stuck in an
 authoritative model of naming.  If the use of words (in spoken language)
 were assigned like this, we would hate it.

 Thanks,
 Marcus


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The next gen P2P secure email solution

[Natanael]

, but not
 directly with you@some.dotcom.
 As with everything else, today's seeds grow into tomorrows garden,
 sometimes
 you just have to thorougly plow under last year's chaff first, that's by
 design.
 =
 viktor...
 E-mail is basically business correspondence.

 - E-mail is stored.
 - E-mail is sent to many people outside your personal social network.
 - Business recipients of email are often subject to corporate and/or
   regulatory policy constraints that are in conflict with end-to-end
   encryption.

 The above list of features can be greatly expanded, and the
 consequences elaborated, but I doubt may on this list truly need
 to be re-educated about email.

 So I will confidently predict that end-to-end secure email will
 remain a niche service used by a tiny minority.
 ...

 Even businesses that one might expect to implement at least encryption
 to the gateway, are in many cases choosing to out-source their
 gateway to 3rd-party providers (anti-spam and anti-virus offerings
 only work with un-encrypted email, and in many cases the provider
 also operates the entire mail store).
 
 [and others also said: tls, dane, skype, smime, ca's, smtp, etc]
 =
 Jerry...
 Medical, Financial
 =
 grarpamp...
 Nothing here changes, only the backend transport between nodes.
 Once your node decrypts the message to your local system pipes,
 you can do all this and more with it. Including running a 'business' node
 and doing whatever you want with the plaintext after your node daemon
 passes it to you. This is not about those ancient protocols. It's also
 about 'messaging' not strictly 'email'... those lines are already well
 blurred, no need to distinguish between them anymore. A 'light'
 messaging client could simply ignore the non transport email headers,
 or use your standard msg@nodekey address.
 Please do not continue to talk about antique tradional centralized
 systems in this thread, except of course to bash and route around them.
 The speed of a real P2P/DHT replacement at scale is a research challenge.
 =
 coderman...
 this would make an interesting bet!  i too believe this to be
 impossible given the constraints.
 =
 grarpamp...
 I'm not so sure about this, look at all the global resources being poured
 into traditional email, and attempts to 'fix' it. Now redirect fractional
 1%
 of those resources and put them into a P2P replacement. That's ftw.
 =
 natanael...
 Say hello to Bote mail on I2P.

 I2P provides encrypted anonymizing networking, Bote mail provides DHT
 based serverless encrypted mailing with public crypto keys as
 addresses (ECDSA or NTRU).

 http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add
 .us to visit it via an inproxy).

 There is also I2P Messenger that is encrypted P2P IM within I2P also
 using public keys as addresses.
 =
 cane...
 You may have a look of I2P Bote it is severless, encrypted mail
 system, address is the public key, P2P based... nice tool.

   https://en.wikipedia.org/wiki/I2P#E-mail
 =
 grarpamp...
  You may have a look of I2P Bote it is severless, encrypted mail
  system, address is the public key, P2P based... nice tool.

 As in another post of mine, I'll be looking at that again.
 My first take was that it stores the messages in the DHT,
 which didn't seem scalable or reliable at all. I may be
 wrong as I read more later.

  Afterwards you can add the I2P Bote plugin, the serverless mail
  system. SMTP- and POP3 support was on the ToDo list some times ago, I

 I think that's working now. And is the general idea, create a strong
 overlay network with a frontend MUA's can speak to.

 As an aside: If you can make that overlay net present an IPv6 tunnel
 interface on the local host, that lets you use any IPv6 enabled
 app over it. I'm doubting the world needs a dozen application
 specific overlay networks. More like just a few classes of network.
 - message based store and forward
 - low latency IPv6 transport
 - data storage and retrieval
 =
 natanael...
 Bote mail doesn't have to be used for it's anonymous properties, for
 me that is just a bonus. For many people it is more than enough to be
 able to know that it is impossible for anybody else than the intended
 recipient to read the message thanks to public key addressing.
 Guaranteed end-to-end security if you can verify the address.
 I don't think anything that doesn't fundamentally rely on public key
 addressing is the (long term) future. There will inevitably issues
 otherwise, including more issues of the type we have with CA:s today.
 For those who want to make it more user friendly, nothing stops you
 from adding a transparent address translation layer where servers
 are involved. When you want to send a message to a person with a human
 readable address at a server, then the server could then reply with
 the public key based address to the mail client, and the user would
 have the option to see what that address is. It could even be logged

Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity

[Natanael]

Den 3 jan 2014 20:42 skrev coderman coder...@gmail.com:

 use case is long term (decade+) identity rather than privacy or
 session authorization.

 eternity key signs working keys tuned for speed with limited secret
 life span (month+).  working keys are used for secret exchange and any
 other temporal purpose.

 you may use any algorithms desired; what do you pick?


 Curve3617+NTRU eternity key
 Curve25519 working keys
 ChaCha20+Poly1305-AES for sym./mac
 ?


 this assumes key agility by signing working keys with all eternity
 keys, and promoting un-broken suites to working suites as needed.  you
 cannot retro-actively add new suites to eternity keys; these must be
 selected and generated extremely conservatively.

 other questions:
 - would you include another public key crypto system with the above?
 (if so, why?)
 - does GGH signature scheme avoid patent mine fields? (like NTRU patents)
 - is it true that NSA does not use any public key scheme, nor AES, for
 long term secrets?
 - are you relieved NSA has only a modest effort aimed at keeping an
 eye on quantum cryptanalysis efforts in academia and other nations?


 best regards

First of all I'd have a lifetime masterkey intended to never be touched
(meant for permanent secure storage) at the top, that signs the long-term
subkey. That means that if your long-term key (which you very likely WILL
access a few dozen to hundred times at least) is compromised, you can
replace it.

My process would be to generate a lifetime masterkey + long-term subkey +
working key, where each long-term key signs new working keys (and revokes
them) as well as new long-term keys, and where the masterkey can revoke and
replace all other keys.

Note that NTRU now has a pledge that it is free for all open source
software (it's even officially on github with that license). They have a
long list of approved licenses where usage is all free.

- Sent from my phone
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Preventing Timing Correlation Attacks on XMPP chats?

[Natanael]

Den 5 jan 2014 13:23 skrev Randolph rdohm...@gmail.com:

 Hi

 - a scrambler could send out from time to time fake messages.
 - an impersonator could record your own chat behaviour and generate
random time and lenght and content data, so it looks like your own chat
 - the main problem remains that from an external analysis you can always
see, that User A is sending (a messge) to User B. This can only be solved
with sending the Message (originally addressed to A) to all connected
people, so as well to B, C, D, E and F. A kind of echo would solve this.

 EMPP (library: http://spot-on.sf.net, echoed message and presence
protocol) has this all and XMPP could benefit from it or - as some discuss
- why not merge EMPP and XMPP or even send echo over an xmpp acccount?
Would a XMPP connection allow a selfsigned SSL connection over/through it ?

 I still wounder, why XMPP is not adding end-to-end encryption and it must
be done over a plugin (OTR).
 D/H key exchange / TLS can be attacked by a man in the middle, especially
if you use :

 User A  - TLS - Own Webserver -   MITM / - Maybe: TLS - - Own
Webserver - TLS - User B

 User A does not know, if the cert between two Webservers is compromised.
Or elsewhere in the chain. Only End to End proves, that you have full
continuity in your TLS chains. And: Is a D/H key exchange for OTR secure
over a broken TLS?

 But: The problem is not securing xmpp, the problem with XMPP is, that you
easily know, who is talking with whoom. This makes no sense to think about
adding a scrambler to it, especially if you are not interested in the
content, but in the social network one maintains.

 From the kids on the block perspective, XMPP is the glorification of open
source. Nothing else has to be there. But is this a differentiating view?
 Form the developer side there are different views:
http://harmful.cat-v.org/software/xml/xmpp/
 If adding fancy helper tools like encryption or scramblers makes this
more easy, dunno.

 Some Dinos have still homework to do and must be regarded outdated until
not a native (and not only plugged) end to end encryption is in.

 This is not liked, we know, but us as XMPP server admins need to be taken
away the possibility to read plaintext. And this is a
transformation we after occurances of the last year have to bear.

 Jabber Servers without Plaintext is the Vision of 2014. And this becomes
real Feb. 22 ?
 2014/1/5 Fabio Pietrosanti (naif) li...@infosecurity.ch

 Hi,

 XMPP networks are now going to be default secured with TLS in their
 client-to-server and server-to-server communications by 22th Feb.

 Most IM client support end-to-end encryption with OTR by default.

 The Federated Architecture make it very scalable and distributed.

 With all that goods of COMSEC in place, we are missing a timing
 correlation protection schema for XMPP traffic, to avoid an adversary
 monitoring your internet communication line to know when you have
 written something.

 POND is a super technology to prevent timing correlation attacks
 (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed
 network so i don't think it would ever get diffused (it's also written
 in GO and my religion does not let me use anything written in GO).

 So i've been thinking that we need a method to achieve protection
 against time traffic correlation attacks on XMPP chat.

 It's possible that, by having a traffic-generator-robot (behaving like
 an XMPP buddy you connect to), and an XMPP client plug-in it would be
 possible to create some kind of constant traffic timing pattern to
 avoid an adversary being able to make timing correlation attacks.

 Something like that would be relatively easy to be implemented.

 This would bring timing correlation attack protection to the already
 existing security stack of XMPP:
 - Client TLS encrypted login
 - Server-to-Server TLS encrypted communication
 - end-to-end encrypted communication with OTR
 - Federated architecture

There are the I2P method of everybody acting as anonymizing relays +
layered end-to-end encryption make traffic analysis nearly impossible (you
don't know where any packet originated from).  There's already a chat
program using it called I2P Messenger, and it's serverless. XMPP has also
already been made to work over I2P.

And there's the batching method (send everything at once in a fixed size
message). Could work well with Moxie's axolotl ratcheting key exchange to
establish PFS encrypted chats.

Both of those can be strengthened by throwing in fake traffic.

I don't like the option of *only* hiding your activity among fake activity
generated only by your own node, it's too easy to attack with things like
statistical means and watching what the node does if you disrupt it's
Internet connection (such as making it somewhat unreliable through DDoS:ing
it's router or whatever).

(And FYI, OTR is secure independently of the channel it's used over if the
keys are verified. But it ONLY protects the contents of the 

Re: [cryptography] Techniques for protecting CA Root certificate Secret Key

[Natanael]

Den 9 jan 2014 00:56 skrev Paul F Fraser pa...@a2zliving.com:

 Software and physical safe keeping of Root CA secret key are central to
security of a large set of issued certificates.
 Are there any safe techniques for handling this problem taking into
account the need to not have the control in the hands of one person?
 Any links or suggestions of how to handle this problem?

 regards

 Paul Fraser

Hardware Security Modules are common. Kind of like smartcards (the chip on
your bank card), but big and fast, and usually supporting far more
protocols. Designed to be very hard to hack or otherwise extract the keys
from.

On the algorithmical level, there is Secure Multiparty Computation plus
Shamir's Secure Sharing Scheme, such that you need a group of chosen period
to work together to use the key to decrypt and sign things, while not
revealing the private key to anybody. The people who developed the Speedz
(spelling?) protocol is marketing a service for this.

- Sent from my phone
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] First public DNSChain server went online yesterday!

[Natanael]

1: Domains expire unless renewed.

2: Transfers are possible.

3: The security model of blockchain based systems like Namecoin is that the
primary chain had the greatest amount of proof-of-work behind it, and you
can't fake the proof-of-work. You can try to isolate a node and provide a
fake chain, but the moment the client sees the current main chain it will
see it has more proof-of-work behind it and dismiss the previous shorter
chain.

- Sent from my phone
Den 8 feb 2014 22:19 skrev Eric Mill e...@konklone.com:

 I just want to be clear on my understanding here. This provides a way to
 register a .dns or .bit domain, and store your registration of that domain
 in a blockchain.

 Then, to guarantee authenticity, you can store a fingerprint of an SSL
 cert in the blockchain, so that anyone can verify that the person who
 registered this domain also created this cert.

 Some questions, though the first two may just be about Namecoin:

 * If you lose your wallet for your name, is the domain forever and truly
 inert?
 * Can you transfer your domain to someone else?
 * How do you prevent an attacker from intercepting and modifying your
 connection to the blockchain itself? What's the security model there?

 I also have a non-trivial suggestion, which is to use JavaScript instead
 of CoffeeScript. Regardless of the merits of the language, it will
 discourage participation from Node/JavaScript developers who do not
 use/know CoffeeScript well (like myself).

 Overall I'm **super** excited about Namecoin and DNSChain, and I've been
 waiting for someone to connect them through traditional DNS. This is such
 valuable work, thank you for being a pioneer on this.

 -- Eric


 On Sat, Feb 8, 2014 at 12:53 AM, Greg g...@kinostudios.com wrote:

 From README.md on GitHub:

 DNSChain (formerly DNSNMC) makes it possible to be certain that you're
 communicating with who you want to communicate with, and connecting to the
 sites that you want to connect to, *without anyone secretly listening in
 on your conversations in between.*

  • DNSChain stops the NSA by fixing HTTPS
 • Free SSL certificates
 • How to use DNSChain *right now*!
  • Don't want to change your DNS settings?
 • The '.dns' meta-TLD
  • How to run your own DNSChain server
 • Requirements
 • Getting Started for devs and sys admins
  • List of public DNSChain servers
 • Contributing
 • Style and Process
  • TODO
 • Release History
 • License


 https://github.com/okTurtles/dnschain

 Previous thread was:

 Re: [cryptography] DNSNMC replaces Certificate Authorities with Namecoin
 and fixes HTTPS security

 Cheers,
 Greg

 --
 Please do not email me anything that you are not comfortable also sharing 
 with
 the NSA.


 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography




 --
 konklone.com | @konklone https://twitter.com/konklone

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Help investigate cell phone snooping by police nationwide

[Natanael]

Den 8 jun 2014 21:52 skrev Jerry Leichter leich...@lrw.com:

 On Jun 7, 2014, at 7:56 PM, Bill Cox waywardg...@gmail.com wrote:

 Is there reliable evidence that putting mobiles in a fridge is any
 better illusory comsec than putting pillows around the door also
 comically exhibited to clueless journalists favored by Showman
 Snowden? Or at least as tall-taled by comical Glenn.

 It's called a Faraday cage.  I'd test it right now, but I think someone
hid my mobile phone in a fridge.

 The problem is that a refrigerator is not a Faraday cage.  Every
refrigerator I've ever used has rubber gasket between the door and the body
of the refrigerator.  It's typically 2-3 cm thick.  Cell phone wavelengths
vary with band, but range from somewhere around 30 cm down to around 8 cm.
 A refrigerator should attenuate the signal, probably quite a bit, but it's
not going to block completely.

 Of course, this assumes that the point of the exercise is to block the
RF.  A refrigerator will also, to some degree, block sounds.  Since nothing
inside the food box of a refrigerator typically generates any noise (and of
course it's not *sensitive* to noise either), there's no reason to design a
refrigerator to be soundproof.  So how much it will muffle outside sounds
is unclear.

 These things are easy to check experimentally, at least to a good enough
approximation to say whether they are likely to be effective for the task
at hand.  If it's important to you ... let us know how the experiments come
out.

 -- Jerry

That leaves my conclusion as that you should stuff the phone into pillows
in the microwave before you put the microwave in the fridge, and then
stuffing more pillows in there.

Then you wrap it all with a lot of layers of blankets and hold them in
place with aluminum foil.

Then you do the same separately for the battery. Because you removed the
battery first, right?

Should only take a single working day or so to achieve.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] WG Review: TCP Increased Security (tcpinc)

[Natanael]

On Mon, Jun 9, 2014 at 7:35 PM, ianG i...@iang.org wrote:

  Original Message 
 Subject: [Tcpcrypt] WG Review: TCP Increased Security (tcpinc)
 Date: Thu, 05 Jun 2014 14:31:12 -0700
 From: The IESG iesg-secret...@ietf.org
 To: IETF-Announce ietf-annou...@ietf.org
 CC: tcpinc WG tcpcr...@ietf.org

 A new IETF working group has been proposed in the Transport Area. The
 IESG has not made any determination yet. The following draft charter was
 submitted, and is provided for informational purposes only. Please send
 your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-15.

 TCP Increased Security (tcpinc)
 
 Current Status: Proposed WG

[...]

 Charter:

 The TCPINC WG will develop the TCP extensions to provide unauthenticated
 encryption and integrity protection of TCP streams. The WG will define
 an unauthenticated key exchange mechanism. In addition, the WG will
 define the TCP extensions to utilize unauthenticated keys, resulting in
 encryption and integrity protection without authentication. This is
 better than plain-text because it thwarts passive eavesdropping, but is
 weaker than using authenticated keys, because it is vulnerable to man-
 in-the-middle attacks during the initial unathenticated key exchange.
 This work is part of the IETF effort to evolve the Internet architecture
 given the latest events of pervasive monitoring (see BCP 188).

 The goal of this WG is to provide an additional security tool that
 complements existing protocols at other layers in the stack. The WG will
 be looking for the designs that find the right tradeoff spot between
 conflicting requirements: to provide reasonable security for the
 majority of connections.  This work will deal with unprotected
 connections, and therefore will focus more on improvements from a
 baseline of no security than on achieving the high standard of security
 that is already available to users of authenticated TLS.

[...]

 - The protocol must not require any authentication or configuration from
   applications or users.  However, hooks for external authentication
   must be made available.  The WG will not work on new authentication
   mechanisms.

[...]

 - must allow the initiator of the connection to avoid fingerprinting:
   some initiators may want to avoid appearing as the same endpoint when
   connecting to a remote peer on subsequent occasions. This should
   either be the default or some mechanism should be available for
   initiators to drop or ignore shared state to avoid being
   fingerprintable any more than would be the case for a cleartext
   session.

[...]

 - An extended API describing how applications can obtain further
 benefits of the proposed extensions. In particular, the hooks for
 supporting external authentication will be defined in this document.
 This will be an informational document.

I've thought of something similar to this when tcpcrypt was new and I
was reading up about Monkeysphere (OpenPGP based Web of Trust
authentication, right now hooked into SSH). I finally wrote up my
thoughts about it in a blog post, and I've just edited it to add some
more thoughts relevant to this. This is very high-level, but could
maybe still be useful;

http://roamingaroundatrandom.wordpress.com/2014/06/06/basic-blueprint-for-a-link-encryption-protocol-with-modular-authentication/

The short summary: what you need to authenticate a link encryption is
a session ID that can be derived from some session specific data, such
as the key generated in the key exchange. The session ID must be
globally unique and unpredictable to any third party. Authentication
would be done by comparing the session ID.

My blog post describes the basic idea of an authentication manager
that supports arbitary authentication modules, where each application
choses which modules to use and for which connection. The
authentication manager would use a specific API to interact with the
link layer encryption, allowing you to create wrappers for various
types of link encryption protocols as long as they are capable of
providing sufficient security. It is the authentication modules that
deals with exactly how to compare the session ID, verify the identity
of the other party and the conditions for when to consider the
connection authenticated.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Weak random data XOR good enough random data = better random data?

[Natanael]

Den 28 jul 2014 18:23 skrev Lodewijk andré de la porte l...@odewijk.nl:

 Hey everyone,

 If I XOR probably random data with good enough random data, does that
result in at least good enough random data?

 I'm working on some Javascript client side crypto. There's a
cryptographic quality random generator present in modern browsers, but not
in older ones. I also don't trust browsers' random generators' quality.

 I'd like to ship a few KB (enough) of random data and XOR it with
whatever the best-available RNG comes up with. That way the user can still
verify that I didn't mess with the randomness, no MITM attacks can mess
with the randomness, but given a good transport layer I can still
supplement usually bad randomness.

 I don't see how it could reduce the randomness to XOR with patterned
data. If someone knows better of this, let me know. If I'm correct that
also means it should be okay to reuse the few KB's should they ever run out
(in this system), at worst it no longer improves the randomness. I don't
expect that to ever happen, and I'd prefer requesting new KB's, but it's
still interesting.

 Could someone confirm this whole thought-train for me? That means, is it
a good idea to (over HTTPS) send some randomness*, XOR it with the
best-available RNG for better randomness? I actually feel pretty confident
about it, just asking for (a few) second opinion(s).

With a mixer function that isn't shitty and lossy/non-reversable, you are
unlikely to lose entropy.

With XOR specifically, then AS LONG AS THE INPUTS ARE UNCORRELATED you will
not lose entropy (you always has at least as much entropy as your most
entropic input). XOR practically anything with random and you still have
random. But if you bitflip the XOR key and XOR that string with the key,
you get all 0's. Not good. There are tons of methods by which they can be
correlated that leak data.
If you know why/how one time pads are mathematically proven uncrackable,
you should know why this is true.

Also, because of how XOR works, you need to make sure at least one of the
inputs have high entropy density if you need to use the output for
something that needs good randomness. Two books of random sentences have
high entropy, but low entropy density (on average one bit of entropy per
character, while each character takes about 7 or 8 bits of space to
represent on the hard drive). Taking 256 bits of XOR'ed random words as a
key for something is NOT good enough. This is when you need strong mixing
like hashing or encryption of the entire input, so that each bit in the
output represents close enough to a full bit of entropy.

Any reversible method can not lose entropy. Otherwise you have found a
magical compression function. Practically any encryption algorithm (all
reversible) that is considered secure can be used to mix your inputs, and
you will not lose entropy (even insecure encryption algorithms also
shouldn't cause entropy loss, unless what you used as a key held most of
the entropy and the encryption algorithm fails to mix it properly with the
plaintext - in which case your plaintext still sets the minimum entropy of
the output).

Most good hashing algorithms will also preserve most of the entropy (for
equivalent length inputs, you can't preserve 500 bits of entropy in a 100
bit hash). If you need 200 bits of entropy, it should be safe to use a
modem hash function with a 256 bit strength to hash all of your inputs.

One example: RC4 produces a biased key stream that you can recover the
original key from if you can get a pure enough version with enough bits of
the raw key stream. Use RC4 to encrypt standard ASCII plaintext (the
literal version) and the attacker can use statistical attacks to remove
enough of the plaintext from the ciphertext to get parts of the key stream,
then the key can be cracked to decrypt everything.
However, that attack fails if you only encrypt high entropy plaintexts as
they then can't be separated from the key stream (same argument for why as
the one time pad security). Also, there's no known easy of cracking
ChaCha20's key stream, it looks random (no known detectable bias) and the
key can't be recovered, so it would resist the above attack.

Using a well defined existing mixing function with your own predefined
random data, like a salt, is fine. It doesn't make it weaker. Even XOR'ing
it in will never make it weaker.

But however, if it is publicly known shared randomness then it only
prevents cross-service rainbow tables and similar batch bruteforce attacks
(adds work to crack them all linearly with the number of services rather
than linearly with number of total users (assuming reused randomness)). It
doesn't help against targeted attacks.

Note that a MITM that can replace that randomness you send out imply that
they can inject malicious code as well, in which case the security is
non-existent. Then they can explicitly attack the RNG to be bad, or
backdoor everything.
___

Re: [cryptography] Complete repository of known playing card ciphers

[Natanael]

Den 10 sep 2014 22:34 skrev Aaron Toponce aaron.topo...@gmail.com:

 I've since put together a site of playing card ciphers, weak and strong.
It's
 still _very_ much a work in progress, but some input would be appreciated:

 http://aarontoponce.org/card-ciphers/

[...]

 I still have a great amount of work to do, such as styling the page,
adding
 videos detailing the algorithms, and computer software implementations of
each
 of the ciphers. I'm sure there are typos and grammar errors galore. I'll
 address those also, including reading flow. I probably have some facts on
a few
 of the implementations wrong also, that need to be cleaned up.

 After the computer software implementations are created, I'll be doing
more
 cryptanalysis on the ciphertexts, getting more hard concrete numbers on
biases,
 patterns, distributions, etc.

Will you attempt to model human shuffling too and see how it affects
analysis? Is there maybe any existing work on that too reuse? I'd like to
know what the minimum requirement would be for a human to achieve a secure
shuffle for these ciphers (in case any of these ciphers would actually be
secure enough given a proper shuffle).
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Do quantum attacks/algos also lead to compromise of PFS?

[Natanael]

Den 24 jan 2015 22:06 skrev Greg g...@kinostudios.com:

 So, I understand that QM algos can pretty much dismantle all popular
asymmetric encryption algos with enough q-bits, but I haven't thought hard
enough to see if they also can be used to compromise communications that
used DH to do PFS underneath the initial handshake.

 Side question: is this the right list to ask this on, or is there other
ones I should try? (Is CFRG appropriate? Metzdowd is annoying with its long
moderation times...)

Key exchange like DH simplifies PFS but isn't strictly necessary. A
mechanism with temporary public keys where your main keys only sign the
temporary keys, and the temporary keys are used for exchange of nonces to
generate session keys (there are presumed quantum secure public key
algorithms!), would be sufficient as well if you delete the temporary
public keys the way DH secrets in regular PFS key exchanges are deleted
afterwards.

There are many hash based signature algorithms, and other types of public
key algorithms like lattice based and many others.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Wandering Music Band

[Natanael]

Den 8 jan 2015 08:03 skrev realcr rea...@gmail.com:

 Hey Natanael, Thanks for your response.


 It's the chain of signatures always published in an accessible way so
that the original members can't doublespend and claim to be the task
group? Otherwise the blockchain approach is useful for you.


 I think the naive solution I proposed in my first message is more
efficient than using Bitcoin, because it does not involve proof of work or
flooding stuff.

The only notable difference is that in my version you are checkpointing the
change in th blockchain.

You still have the very same form of signing, but you sign a slightly
different message (transfer of a colored coin, one Satoshi worth of
Bitcoin, to a new address) instead of group members XYZ are now the
official group instead of ABC.

 The band S doesn't publish the signatures. They only show the signatures
whenever I ask them.

Is secrecy a requirement? If so, take a look at Zerocoin/Zerocash (not yet
released, though). It uses Zero-knowledge proofs for secure mixing of
coins to preserve privacy. You could also chose to have the group
periodically rekey and transfer the colored coin even if there's no change,
just to hide when the change actually happens.

 The group setting is also solved as-is thanks to both the multisignature
support (m-of-n for up to 15 people), and thanks to ECDSA threshold group
signatures if you prefer these (I'm assuming they also don't limit you to
15 members).

 Using a multisignature scheme I can probably get much shorter signatures,
which is cool.
 I will still have to remember the identities of all the signers, and the
set of signatures to be remembered grows linearly with respect to time.

If you're willing to involve custom Zero-knowledge proofs, you could
generate one showing that a valid chain of signatures exists between the
first and last group. Generating it is essentially O(n), verification is as
good as O(1).

This approach also works with the blockchain such that a person who knows
the current blockchain headers and the first colored coin transaction only
needs to be shown the latest colored coin transaction plus the
Zero-knowledge proof (chaining together multiple ZKP's can make this
O(log(n)) over long periods of time).

Telling them directly what exact block the latest transaction is in means
they just have to look up the Merkle tree hash in that block header from
their index, confirm that the given colored coin transaction is in there
and that the ZKP is valid. To be sure there's been no more recent transfer
of the coin, they look in their Bitcoin blockchain index (one database
lookup of a hash, for full nodes) or ask other nodes if the coin has been
moved yet or not (for lightweight SPV nodes).

Then they proceed as before, show what the address is composed of and prove
they have a private key that is a member of the group.

 Assuming that I use some kind of Threshold signature scheme, how can I
transfer the secret parts to the next members in the band, so that parts of
the secret don't leak to previous members?
 Most of what I read about threshold signatures assumes that some that
some trusted dealer deals the secret parts to the participants.
 How can I move the secret parts to the new band without a trusted dealer?

Don't move it, don't forward shares. Create a new group public key. All
members have one unique share that they are supposed to never reveal. Each
version of the group combine the shares of those members to create their
public key.

 Someone in this thread has mentioned Shamir secret sharing. Considering
this idea,

Insufficient, you need to recover the plaintext at some point with trusted
hardware and trusted users.

 How can I avoid the possibility that some set of corrupt ex-band members
will gather and combine their secret parts?

This is essentially the doublespend problem in cryptocurrencies. The status
of being the right descendant of the group can be represented by a token
which must not be duplicated or claimed to be passed on to multiple groups
(conflicting doublespends). Bitcoin tracks it by enforcing one and only one
official self consistent version of events in the blockchain.

You can only prevent old members from claiming to be the real group by
making some kind of checkpointing information public, with trusted
timestamps. (Unless you forcefully delete their private keys, which is
nearly impossible unless only stored on trusted hardware like a HSM.)

If you only publish hashes to keep the activity secret until it has to be
used, then each member must remember all key activity that's been
checkpointed to show exactly what all hashes represent to prove that
they're the legitimate descendant. All group members MUST at all times
agree on ONE AND THE SAME official public chain of commitments which
represent the official chain of events.

If previous members can not be fully trusted, you CAN NOT rely on any
non-public activity that can be repeated in contradicting ways. Using
one-time

Re: [cryptography] The Wandering Music Band

[Natanael]

Den 8 jan 2015 11:54 skrev realcr rea...@gmail.com:

 Hey, thanks again for the reply.

 The only notable difference is that in my version you are checkpointing
the change in th blockchain.

 You still have the very same form of signing, but you sign a slightly
different message (transfer of a colored coin, one Satoshi worth of
Bitcoin, to a new address) instead of group members XYZ are now the
official group instead of ABC.


 I disagree with you, or maybe I have misunderstood you idea. I think that
Bitcoin is not related here.

 Bitcoin is all or nothing. If I want to use it, all the participants of
the network have to be part of it.
 That means that all the participants of the network have to compute
hashes all the time.
 In addition, every Bitcoin transaction involves all the participants of
the network.

I think you overestimate the impact of using Bitcoin. It isn't all our
nothing as not all members need to be full nodes, in fact none of them have
to be. While it is true that all full nodes must store all the
transactions, and that it gets forwarded in the network among most online
nodes as it gets published, only the latest one would need to be kept in
their index of the unspent outputs (UTXO set) from the blockchain. The
Bitcoin developers is constantly working on scalability, and the network is
meant to one day be able to handle thousands of transactions per second
(this is years off, though). The blockchain can easily be stored on MicroSD
cards!

Verifying the headers alone for decades worth of hashes takes at most
minutes on smartphones. And that's a one-time job per header hash, per
device. Each new header takes much less than a second to process.
Publishing and verifying the colored coin transactions is trivial too.

 Secrecy is not required. I meant to say that the band has the
responsibility of keeping the signatures and show them on demand.

You still don't get any meaningful security if old band members are assumed
to be untrusted and you don't use a public checkpointing mechanism.
Transfer of the title of being the real group must be a one-time only thing
for each version of the group, and must be impossible to backtrack from.
Bitcoin enforces this by design.

Other standard public checkpointing mechanisms don't verify if there's
conflicting messages or not, so then ALL messages that has been
checkpointed must be stored.

There are cryptocurrencies with similar functionality (doublespend
protection, conflicting assignments not allowed) and other trust models (no
proof-of-work for chain selection). As an example, Ripple is federated, a
set of trusted nodes agree on the order of transactions. This removes most
of your performance related issues. But I don't trust it if security is
important, it seems too ad-hoc. Then there's proof-of-stake which is very
problematic for a million different reasons (no guarantee there will be
concensus), but the network performance issues from Bitcoin remains here.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Wandering Music Band

[Natanael]

Den 7 jan 2015 22:14 skrev realcr rea...@gmail.com:

 Hey,
 Thank you for all the responses. I figured out that I left some important
details out, probably because I thought about it for a long time. I'm sorry
about that.
 I will try to formulate it again:

 Assume that the world contains correct people (People you can trust) and
corrupt people (Those you can't trust).
 Also assume that the world has a majority of correct people (If it helps,
you may assume 3/4 correct people).

 I am given a set S which contains k members (The music band). Assume that
a majority of this set is correct.

 From time to time:
 -  A random person (From the world) joins the band. (With good
probability this new member is correct).
 -  A random person (From the band) leaves the band.

 (
 The band always have at least k people.

It's the chain of signatures always published in an accessible way so that
the original members can't doublespend and claim to be the task group?
Otherwise the blockchain approach is useful for you.

The Bitcoin blockchain solves the problem of trustlessly transferring
ownership. The group setting is also solved as-is thanks to both the
multisignature support (m-of-n for up to 15 people), and thanks to ECDSA
threshold group signatures if you prefer these (I'm assuming they also
don't limit you to 15 members).

Group S_1 creates a colored coin by sending the smallest denomination of
Bitcoin to an address created using the public keys of all current members
(must not be mixed with other coins). The threshold is defined such that m
must be larger than half of n (the size of the group).

When any change is made, group S_2 is then created and the colored coin is
sent to a new address created from the public keys of all members in this
new group, and the threshold is adjusted if necessary.

Keeping only the blockchain headers and asking Bitcoin nodes for the
transactions following the original colored coin transaction (SPV security
model), you can track it to the latest address, and thus to the latest
version of the group, the current descendant (S_n).

You can verify that the group member(s) you meet is indeed part of the
current version of the group by asking them to sign a nonce as a challenge
with their private key and show the rest of the public keys from the group
(such that the Bitcoin address can be recreated, to verify his public key
is part of the group).
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Feedback requested: ECC anonymous signatures with per-message revocable anonymity and pair-wise message linkability

[Natanael]

@Richard Clayton: I'm aware of Fawkes signatures. They are somewhat
applicable, but in some circumstances they aren't useful and/or safe.

Here's the best case stateless implementation of Fawkes signatures that I
can see that matches this usecase;

Use a seed and a counter to derive commitment values, which are then
committed with hashes in the message and revealed in the next message in
the chain (for keeping your pseudonym alive). To remain stateless, you also
derive counter encryption keys from the same seed and put encrypted
counters in the messages. To create a new message, you must access your
previous one to decrypt the counter so you can safely iterate it.

Multiple messages can also be posted without being linked to previous
messages (don't reveal earlier commitments), and later linked by a single
message revealing multiple commitments. But in this case of not having
simply a single chain of messages, tracking which commitments you have
revealed already requires additional state to be kept unless you have
access to all your messages (tracking which ones is yours could be made
stateless by having an iterated identifier value in the message, derived
from the seed, where you recalculate all identifiers and look up those
messages - but this access leaks metadata that can correlate your different
messages to your identity).

This scheme breaks if you forget the counter and also fails to access the
most recent message (such as if you have to go offline or can't access the
closed network with your most recent messages, and don't have the
electronics with you where you keep the counter updated). Then you'll
repeat your values and keys and the second message will look like a
forgery. If you screw up and publish the message to early after
timestamping its hash as a commitment, you can also break your pseudonym
through causing uncertainty about if the new commitment in the disputed
message is valid or not.

Due to uncertainties in the general perception of timestamping in various
cases (a single somewhat credible entity claiming to have seen the message
earlier than the timestamp causes uncertainty), Fawkes signatures are most
effective even used towards a small target audience (as higher assurances
can be achieved regarding when it really was first seen).

Accessing your most recent message to decrypt the counter can also put you
at a greater risk of local attackers.

Den 14 apr 2015 22:00 skrev Mattias Aabmets mattias.aabm...@gmail.com:

 Why are you making it so complicated?

1: Its a mental exercise, and I want to see if I can construct something
that actually could work. Keeping it too simple wouldn't be an interesting
mental exercise.

2: Its (subjectively) a neat construction.

3: Flexibility. You've got plenty of freedom even after posting a message
in deciding what to link to what and how. You can link together multiple
messages in independent sets to establish two or more independent
pseudonyms to build reputation. You get to decide when to reveal your
identity.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Feedback requested: ECC anonymous signatures with per-message revocable anonymity and pair-wise message linkability

[Natanael]

This started with the following Reddit thread:
http://www.reddit.com/r/crypto/comments/32gh1v/looking_for_signing_algorithm_that_keeps_signee/

The goal is to be able to publish signed messages anonymously and then
later on prove it was you who signed them, at a time of your choosing.

NOTE: I'm not a professional cryptographer, just a hobbyist, but I think
I've got a good grip of how things work. I'm willing to learn, feel free to
point out errors or flawed assumptions! It might be complete crap, or it
might be useful. I'm trying to keep it reasonably formal, but there's
probably some ambiguity left. I'm happy to answer questions.

Bonus features:
1: To be able to publish multiple messages without revealing at that time
that they're signed by the same person.
2: To be able to selectively link together multiple sets of arbitarily
chosen messages at a later point in time.
3: Not needing to store any state, so you don't need to store any data
beyond your original private key. The random numbers needed are derived
from values you already have whenever you need them.

Here's the most recent version of it that I'm considering;

You start off with a preexisting ECC keypair publicly associated with you,
with private key x_p and public key g^x_p (p means known publicly). You
have a message m_i (there may multiple messages, i is a variable that
identifies the current message). To sign a message anonymously, you create
a new keypair. To be able to prove it was created by you at a later point
in time, without allowing others to claim authorship, this is how it is
created;

You first compute a unique per-message committed value H_ci = HMAC(m_i,
x_p). From that you compute a per-message value from that used for
derivation of a new ECC keypair, H_di = HMAC(H_ci, m_i).

To derive the new keypair (note that we are using the ECC versions of
multiplication/division, etc, not arithmetic), you compute the derived
private key x_i = x_p * H_di and the derived public key g^x_i = g^x_p +
H_di (deriving new valid keypairs is a neat feature of many ECC
implementations; also deriving nonces from the the private key + the
message has precedence in deterministic signatures). This keypair is used
to sign m_i.

To later on prove that you were the signer of the original message, you
compute and publish H_ci, signed with both keypairs x_p;g^x_p and x_i;g^x_i
(you probably should also include m_i and g^x_p and g^x_i in the signed
message). Thus anybody can compute g^x_p + HMAC(H_ci, m_i) = g^x_p + H_di =
g^x_i and validate both signatures to confirm the following;

1: That the signing keypair was derived from the original keypair, using a
value derived from that message (thanks to the hash commitment, it isn't
merely random), so the keypairs are related (the exact origin of H_ci is
irrelevant for verification, it just acts as a committed nonce/salt, H_di
is the important value; H_ci is derived from the message + main private key
in order to keep things stateless).
2: That as a result of 1, the message must have been known to the holder of
the original keypair at the time of signing, as the signature can't be
created before the keypair is created (this binds the message to your
keypair such that nobody else can claim authorship in contradiction to you
- assuming your original signature of the message was preserved when the
message was published and known by the verifying parties). Timestamping a
hash of the signed message before publishing can assist you in your claim
of authorship as you can prove your signature is the earliest timestamped
one.
3: That both public keys represent *valid* keypairs which you hold and can
sign messages with.
4: That you hold the private keys of both keypairs *simultaneously*
(decreases risk of collusion between the signer and another party).
5: That you approve of this message with both the signing keypair and
your main keypair (you intend to prove authorship and link the keys).

It is also possible to link together pairs of messages to the same
pseudonymous identity without revealing at that time that that they're
related to your main keypair, and you can even create a chain of these
proofs for multiple messages, which in turn can be linked to your main
keypair at will;

You compute l_ij = x_i/x_j = x_p * H_di / x_p * H_dj (where l means linking
value, j represents the second message), where g^x_i + (x_i/x_j) = g^x_i +
l_ij = g^x_j. l_ij here has the same function as H_di above, and you sign
l_ij with both keypairs x_i;g^x_i and x_j;g^x_j, thus proving you hold both
keypairs simultaneously and intend to link them (again, you should include
g^x_i, g^x_j, m_i and m_j in the signed message).

This version do not show that you already knew one message while signing
the other like it does with showing the tie between x_p;g^x_p and
x_i;g^x_i, so this proves nothing about the origins of the keypairs, but
you probably don't need to do that either in this case. You can however
later on decide to link the messages to 

Re: [cryptography] Fwd: The Wandering Music Band

[Natanael]

Den 10 dec 2015 21:02 skrev "realcr" :
>
> It has been a while, but I think I know now about an idea to solve this
problem.
> I really appreciate all the help I got from your responses.
>
> I wrote a document that explains it here:
>
>
https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html
>
> Abstract:
>
> The Trusted Supernode is an abstract idea for a distributed secure and
efficient banking system. This system allows payment operations that
disturb only small amount of participants. It overcomes adversarial attacks
by applying a useful proof of work, combined with node mixing.
>
> The Trusted Supernode bank system relies at its core on a special form of
trusted entity called the supernode. In addition to its ability to manage
payments, the supernode should allow to securely exchange computation and
storage services for money.

Interesting approach.

So you create a top-level supernode W as a gatekeeper? How do you handle
the abnormal incentives to become corrupted for these members? And hacking
risk? What about node selection attacks (including RNG manipulation)
performed by existing bad members trying to increase the share of bad
nodes? Any kind of trust / reputation / behavior based node priority in the
node selection?

Then of course having separate T_user's risks synchronization issues too,
how do you ensure consistency with 3 or more of these at once,
simultaneously sending and receiving multiple requests?

And network disruptions and hacking with zerodays are also not dealt with.
Also, it looks like you didn't deal with the risk of good nodes that used
to be in the group turning bad after the fact and faking the history, which
is really critical over long time periods. And overall, it looks easy to
disrupt by messing with the network.

Also what if somebody prevents a supernode from communicating with good
nodes (a variant of sybil where you isolate the target, an eclipse attack)
during node selection? Forcing the choice of bad nodes?

And your risk calculation is a point-in-time value for one single
supernode. What's the aggregate risk over time, given some defection rate
and some transition rate? The birthday paradox is relevant, for example.

While still not yet practical, Zero-knowledge proofs would enable signature
set compression.

As far as I can see, in stable trusting groups it can work reasonably well
even if large, but I doubt it can work in the long term in fully open
groups. In the latter case, you can not effectively defend against being
overrun by dishonest users.

Where I can see this being applied is for something like say cooperating
groups of sensors (maybe environmental sensors) with different owners
(different research teams?) in a large mesh network *without any explicit
adversaries* (but maybe some greedy users), where you can't guarantee a
reliable link to any trusted servers. So they coordinate themselves the
best they can with an algorithm like yours. There must be a low incentive
for malice.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Secure universal message addressing

[Natanael]

- Sent from my phone
Den 5 apr. 2016 09:17 skrev "John Gilmore" :
>
> > The key idea here is that you get to have *one* identifier for yourself
> > under your control, that you can use everywhere, securely.
>
> The key idea here is a bad idea.
>
> I don't want everyone I interact with to have the same identifier for
> me.  That's the problem with Social Security Numbers.  With a single
> identifier, all the interactions with me can be cross-correlated to
> track me everywhere I go.  Typically this is done NOT for my
> benefit, but to give some third party an advantage over me.

No problem. This is a per-nickname identifier. Use temporary disposable /
throwaway accounts or context specific accounts if you wish. Then you won't
have everything linked to the same account.

> > OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based
> > protocols too. And many many more.
>
> And, from my point of view, this is why they died.  I had zero
> interest in helping third parties keep track of me everywhere, using
> the same identifier on widely varying sites.  It's already hard enough
> work to keep Google out of my underwear when I don't even have an
> account with them.  If I had the same account everywhere?  Let's not
> go there.  "Login with your Facebook account?"  No thanks!!!

The type of tech Mozilla Personas (or U2F) was using to anonymize the
original account you connected with can be reused, although that would
break the universal addressing aspect.

Or how about this - you can link multiple profiles / personas / nicknames
to your account, including creating throwaways, and get to chose which one
to link third party services too when you register with them.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Secure universal message addressing

[Natanael]

I'm crossposting this to a few lists, a few of the relevant mail archives
are here for those who want to follow the replies on the other lists;

http://www.metzdowd.com/pipermail/cryptography/
http://lists.randombit.net/pipermail/cryptography/
http://www.ietf.org/mail-archive/web/endymail/current/maillist.html
https://moderncrypto.org/mail-archive/messaging/2014/thread.html

#

After spending way too much time thinking about how to design a secure
universal message passing platform that would work for both IM, email, push
messages and much more, I just ended up with a more complex version of XMPP
that won't really ever have lower latency, be scalable or be simpler to
operate or even be secure at all. So I dropped that idea.

Then I ended up thinking about addressing instead. If building one single
universal communication protocol is too hard, why couldn't it still be
simple to have one single universal protocol for identifying recipients /
users? It would allow each user to have one single unique global identifier
which can be used to find out which communication protocols each other user
supports and how to connect to them.

Email address type identifiers are already familiar and won't go away. We
are practically already heading this way with email too;

Given that we have the combo of protocols like DMARC, DKIM, SPF, TLS,
DNSSEC+DANE and of course the very relevant WebFinger for user profile data
(https://webfinger.net/), and that we have companies like Google, Yahoo and
Microsoft working on SMTP STS, we are already building much of the
infrastructure necessary for secure addressing. Every server / node would
continously check which one's the strongest protocol supported by each
other server / node they've communicated with recently, refusing to connect
over weaker protocols.

#

Add in transparency logs (perhaps Keybase style) and you've got very strong
security for the users. Stopping downgrade attacks suddenly becomes more
than plausible when there are reliable ways to detect if a server truly
supports secure protocols or not, and MITM becomes hard to hide if the
sending client / server / node always logs the recipient's server's
responses (making forged replies trivially provable, hurting the server's
reputation in seconds by publishing the conflicting log entries). A
Perspectives / SSL observatory model would also drastically improve the
detection rate for tampering.

#

That setup just lacks one capability which I consider major - playing well
with P2P networks lacking classical domain names. Not all users will be
using (fixed) servers (or even IPv4/6 addresses), so perhaps the domain
part of email type addresses could be a domain name format that specifies
that it identifies a P2P node and its protocol (like a Namecoin profile or
an I2P node holding your profile data, or a CJDNS node). Including public
key identifiers in the addresses would most likely be necessary, unless
you're dealing with protocols like Namecoin for fetching profile data.

Those who wants to place their own P2P nodes in the domain field could do
that, having that node carry the profile data which explains how to connect
to you (which would of course require that those you communicate with can
connect to your P2P node), instead of using a third party server. Most
people probably won't opt for this, but it should be possible.

Where the users or (end user trusted) servers are identified by public keys
in the addresses, it could be possible to have public translating proxies
for P2P protocols (kind of like i2p.to and the Tor equivalent, "inproxies")
without any loss of security.

#

The user experience would end up looking like Keybase.io, but with their
account ownership proof process looking more like the OAuth process
(usually initiated via the third party service/client by entering your
email to register after logging in), where most likely it would be your
existing email provider offering this addressing service.

Every messaging system you add would be linked to your account, both server
based ones and P2P ones (with their respective unique user identifiers),
allowing anybody who want to message you securely to detect that you
support protocols with better security than the arcane SMTP. If both sides
supports this protocol and a hypothetical email2 protocol that's tagged as
an upgrade over SMTP, no mail between you would ever be sent over SMTP. As
more email servers upgrade they would quickly start to detect that the rest
of them also supports stronger security, and upgrade the security for all
the users silently.

It would behave like account addressing within Google's suite of protocols
such as email + IM via Hangouts + Google Cloud Messaging + Google Docs,
etc, where the same email address is the account identifier for them all,
except that this would be an open universal protocol.

The recipient of a message from a third party service you started using
wouldn't be getting an invite email (invite emails are getting 

Re: [cryptography] [Endymail] Secure universal message addressing

[Natanael]

Den 4 apr. 2016 19:23 skrev "Sean Leonard" :
>
> I think it’s called a URI.
>
> Any “universal” address is going to have to have embedded info about the
protocol or system that it is addressing. See URI.

People see URL:s and think websites, they see email addresses and think
people.

OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based
protocols too. And many many more. They all shared the URI. It was
*something extra* people has to remember and share besides their email.

If we're going with an URI, what do we put in the protocol field? Do we go
for a magnet link type address where you encode an URL in the URI if you're
using a server, and otherwise specify a protocol and public key, etc? Next
question, the more serious one; who'll even try to share that URI? Who's
gonna read it over the phone? Exactly nobody. It will be forgotten.

Or do we go with HTTP + special HTML tags on websites like OpenID did and
go for standard URL:s? Besides the tendency of HTML tags to get broken in
website redesigns, the total lack of an enforceable standard for how
transparency logs could be implemented (how will you even know where these
tags can be found on arbitary domains, since few will accept using your
page naming conventions?), HTML parsers tend to have bugs.

Also, that situation would also practically by default lead to developers
forgetting about other lookup/connectivity protocols, like Namecoin and
I2P, where their addresses won't even be recognized.

That's why I stick to email addresses here. We can actually enforce a
secure way to implement the lookups if we use them.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Number of hash function preimages

[natanael . l]

He actually asked two different questions on #2, if all hashes have collisions 
and if all messages have collisions. For MD5, the latter is almost proven 
true. There's a tool that let you enter two plaintexts, and then it generates a 
shared appended string (like md5(text_a+string)=md5(text_b+string)) that gives 
them the same hash. Not exactly the same, but relevant.

If there's direct collisions for all hashes and/or messages depends entirely 
on the algorithm. There could be one hash for SHA256, for example, which only 
has *one* message that can generate it. Then there are no messages or hashes 
colliding with those, and the answer to both of the questions in #2 is no.

Also note that if there's collisions for all hashes, there's collisions for all 
messages, but the reverse doesn't have to be true.


2012-03-10 12:33 skrev Timo Warns:

On 2012-03-09, natanae...@gmail.com wrote:
 On #2: There MUST be collisions with fixed-length hashes. But with 2^256
 possible results and sufficiently strong algorithms, it will not matter IRL. 
 We
 won't find any collisions ever. But of course, the algorithms MIGHT be weak.
 MD5 was thought to be strong when it was new.


I think Florian asked whether there exists a collision for _every_ hash
value.


Cheers, Timo

___

cryptography mailing list

natanae...@gmail.com
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Haystacks and Needles

[natanael . l]

Sounds good, but they're already asking for backdoors to the haystacks...


2012-03-27 17:45 skrev Ed Stone:

Just as immunizations protect not only the person immunized, but also help 
protect the community from contagion, wouldn't more encrypted content have a 
public benefit through increasing the costs per nugget found and cause a 
narrowing of focus on those communications where there is probable cause or at 
least reasonable suspicion, versus wholesale hoovering of the spew?


While there are many technical defenses in systems, procedures, algorithms and 
implementations, wouldn't a vast increase in encrypted content also add 
substantially to the security of individual encrypted content by increasing the 
number of haystacks (costs and time) per valuable needle?


Rather than security through obscurity, more haystacks mean that encryption, 
being more common, is less of a red flag of suspicion, and that selection among 
encrypted content for the crackers has to be more discriminating.

___

cryptography mailing list

cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] crypto.cat

[natanael . l]

Again - SSL flaws, bad server, etc... Maybe a buggy browser. Can you imagine a 
bug allowing JS injection in any tab? Post a bit.ly link and wait for keys... 
Bugs like that have existed before.


2012-04-01 02:54 skrev James A. Donald:

On 2012-04-01 7:51 AM, natanae...@gmail.com wrote:
 It's running in a browser using JS...


To attack JS, the attacker needs to induce the victim to open the
attackers web page at the same time as the attacked web page, and
successfully apply a cross site scripting attack. The simplicity of the 
crypto.cat web page is apt to make cross site scripting attacks difficult.

___

cryptography mailing list

natanae...@gmail.com
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography