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

[Peter Todd]

On Fri, Jun 07, 2013 at 10:02:51AM +0300, ianG wrote:
> The big example here is of SSL.  In v1 it was vulnerable to MITM,
> which was theoretically claimed to make it 'insecure'.  In practice
> there was no evidence of a threat, and still little real evidence of
> that precise threat.  Fixing the MITM in SSL v2 caused the utility
> to fall and costs to skyrocket, which meant that it failed in its
> overall mission and maintained its "credit card" mission only by
> much handwaving and ignoring of other issues.

When it comes to browsers, the way SSL/HTTPS has been presented to users
is maddening.

Every time a user sees the scary "unsigned SSL certificate" warning
we're basically telling the user that their security is worse with SSL
than without. I've seen multiple comments on sites like slashdot by
sysadmins and programmers who don't understand crypto discouraging
the use of HTTPS unless you have a CA-signed certificate because it
makes you vulnerable to a MITM attack... when HTTP is vulnerable as
well. Somehow people actually have this misunderstanding.

What browser vendors should be doing is to display http and https
URLs identically in the URL field and focus on the "Green URL" side of
things to make it clear when the connection is actually authenticated.
It's probably not a bad idea for a *manually entered* https URL to
result in a warning if the certificate is unsigned, but the general case
should simply have identical behavior given the identical worst-case
security.


The PGP world is the same. We would be far better off if we focused on
making PGP simple and easy enough that people actually use it; focusing
on the web-of-trust does more harm than good. Again protection from
passive evesdroppers is a huge improvement on the status quo even
without any protection from active evesdroppers. For one thing active
evesdroppers leave evidence of their actions.

-- 
'peter'[:-1]@petertodd.org
002ef32132cbc3d519800a1f348a51b3ee59f9686e52d92d8734


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [ipv6hackers] opportunistic encryption in IPv6

[Peter Todd]

On Wed, Jun 12, 2013 at 05:59:38PM +0200, Eugen Leitl wrote:
> Here, I just don't understand the logic.  To me, encrypting without
> authenticating buys you absolutely nothing, except to burn CPU cycles
> and contribute to global warming.  In the *vast* majority of
> networking technology we use, modifying data in transit is just as
> easy as passively reading data in transit, within a constant factor.
> (That is, in a big-O sense, these are the same difficulty.)

So what?

Being able to detect if you are being attacked, even if most people
don't bother, is a huge step forward over having no way of knowing at
all.

-- 
'peter'[:-1]@petertodd.org
002c90d9b4f79320cf4b85fef8165be49be8ebcc29be25d353db


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] What project would you finance? [WAS: Potential funding for crypto-related projects]

[Peter Todd]

On Tue, Jul 02, 2013 at 12:25:50PM +0200, Adam Back wrote:
> I think it time to deprecate non-https (and non-forward secret
> ciphersuites.)  Compute power has moved on, session cacheing works,
> symmetric crypto is cheap.

A reasonable use for the $3k the OP is talking about would be to add
node-to-node SSL encryption w/o mandatory authentication to Bitcoin
actually.

I'm pretty sure $3k could hire a developer to implement that - I'd do it
msyelf and I think the hourly rate would be reasonable - while
Better-Than-Nothing-Security is probably a more expensive project. But
if you can get significantly more funds BTNS probably could have more
widespread impact.

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


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Authenticated Time Synchronization

[Peter Todd]

Have you considered merkle trees for scalability?

Specifically a client can generate a unique 128-bit nonce and have the trusted 
server timestamp it by signing a message including the nonce and the current 
time T. If the time between the request and the reply was dt, the actual time 
must be in the range (T, dt)

We can then extend this to an arbitrary number of clients with a merkle tree 
and one or more levels of untrusted servers. The servers combine all the nonces 
they receive in some time interval t into a merkle tree, then timestamp the 
digest of the tip of that tree. The clients then receive the merkle paths from 
the server, a proof of log2(n) size.

If a client doesn't trust the server at all, they know the time is within (T, 
dt); if they are willing to place some trust in the server the server can 
measure the interval between when they got the request and sent the proof, dt', 
and the client can take that into account for a more precise time. 

Of course there are advantages and disadvantages to all these methods, but the 
above is particularly good for the majority of clients like desktops setting 
their clocks automatically that probably just need the time accurate to within 
a second or two. Eg the ntp.ubuntu.com servers and similar ones. Reducing the 
number of timestamping servers that need to be trusted with private keys is a 
very good thing. What you described below is I think compatible with the above 
- I'm on vacation and didnt look too closely - but it'd be good to ensure that 
the way to do so efficient and obvious. 

On 2013-09-01, at 10:45, "Stephen Röttger"  wrote:

> Hi Everyone,
> 
> We're currently working on a new RFC for authenticated time
> synchronization (NTP/PTP) since the current approach has major security
> vulnerabilities and would like to have some feedback.
> 
> You can find the most recent version of the draft here:
> http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00
> 
> And the previous discussion on the mailing list of the working group:
> http://lists.ntp.org/pipermail/ntpwg/2013-July/001886.html
> http://lists.ntp.org/pipermail/ntpwg/2013-August/001899.html
> 
> I would be especially interested in feedback for the client-server
> synchronization and will outline the protocol shortly.
> The major requirements for this protocol are as follows:
> * the server should not keep a state about the clients
> * it shouldn't be a cpu hog (in order to not influence the
> synchronization precision)
> 
> That's why we came up with the following protocol:
> The server keeps a 128 bit secret S_s and has a public key and a
> certificate signed by some certificate authority.
> 
> C -> S: request a shared secret (cookie request)
> The client sends his public rsa key C_pub to the server
> C <- S: cookie response
> The server calculates a secret, unique to the client:
>  C_cookie = MSB_128(S_s || H(C_pub))
> And sends it back to the client, encrypted with C_pub and signed
> 
> C -> S: Time request
> The time request again includes C_pub (or H(C_pub)) and a 128 bit nonce
> C <- S: Time response
> The server calculates C_cookie (using C_pub) and uses it to append a
> MAC to the time response (which again includes the client's nonce)
>  MAC = HMAC(C_cookie, time_response)
> 
> The hash function H in this case should be at least sha2.
> Note that the nonce in the time requests/responses is not in the current
> draft yet.
> 
> Regards,
> Stephen
> ___
> 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] [Bitcoin-development] REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and others

[Peter Todd]

2.17BTC ($267USD) pledged to the SHA1 reward to date.

It's amusing that the Bitcoin scripting language lets you pull off
stunts like this; annoying that the scripting language is too limited to
pull off much more than this. In any case I'd love to see proof of a
SHA1 or RIPEMD160 collision previously hidden away in some government
lab to leak.

- Forwarded message from Peter Todd  -

Date: Fri, 13 Sep 2013 02:07:58 -0400
From: Peter Todd 
To: Bitcoin Dev 
Subject: [Bitcoin-development] REWARD offered for hash collisions for SHA1, 
SHA256, RIPEMD160 and others

Rewards at the following P2SH addresses are available for anyone able to
demonstrate collision attacks against a variety of cryptographic
algorithms. You collect your bounty by demonstrating two messages that
are not equal in value, yet result in the same digest when hashed. These
messages are used in a scriptSig, which satisfies the scriptPubKey
storing the bountied funds, allowing you to move them to a scriptPubKey
(Bitcoin address) of your choice.

Further donations to the bounties are welcome, particularly for SHA1 -
address 37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP - for which an attack on a
single hash value is believed to be possible at an estimated cost of
$2.77M (4)


Details below; note that the "decodescript" RPC command is not yet
released; compile bitcoind from the git repository at
http://github.com/bitcoin/bitcoin

SHA1:

$ btc decodescript 6e879169a77ca787
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 
OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP"
}


SHA256:

$ btc decodescript 6e879169a87ca887
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA256 OP_SWAP OP_SHA256 
OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "35Snmmy3uhaer2gTboc81ayCip4m9DT4ko"
}


RIPEMD160:

$ btc decodescript 6e879169a67ca687
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_RIPEMD160 OP_SWAP 
OP_RIPEMD160 OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay"
}


RIPEMD160(SHA256()):

$ btc decodescript 6e879169a97ca987
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH160 OP_SWAP OP_HASH160 
OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6"
}


SHA256(SHA256()):

$ btc decodescript 6e879169aa7caa87
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH256 OP_SWAP OP_HASH256 
OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "3DUQQvz4t57Jy7jxE86kyFcNpKtURNf1VW"
}


and last but not least, the absolute value function:

$ btc decodescript 6e879169907c9087
{
"asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_ABS OP_SWAP OP_ABS OP_EQUAL",
"type" : "nonstandard",
"p2sh" : "3QsT6Sast6ghfsjZ9VJj9u8jkM2qTfDgHV"
}

For example, this pair of transactions created, and then collected, an
absolute value function bounty:

010001f3194f7c2a39809d6ea5fa2db68326932df146aaab7be2f398a524bd269d0b628a473044022039bc13cb7fe565ff2e14b16fbc4a9facd36b25a435d2f49de4534463212aeaee022076413c7591385cd813df37d8104dd8110745c28178cef829b5ab3e56b7c30d22014104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e714178303207e75001976a9149bc0bbdd3024da4d0c38ed1aecf5c68dd1d3fa1288ac126a6e879169907c9087086e879169907c908740420f0017a914fe441065b6532231de2fac563152205ec4f59c7487

010001f18cda90bbbcfb031c65ceda17c82dc046c7db0b96242ba4c5b53c411d8c056e02000c510181086e879169907c908701a0bb0d001976a9149bc0bbdd3024da4d0c38ed1aecf5c68dd1d3fa1288ac

Specifically with the scriptSig: 1 -1 6e879169907c9087


Notes:

1) We advise mining the block in which you collect your bounty yourself;
   scriptSigs satisfying the above scriptPubKeys do not cryptographically sign
   the transaction's outputs. If the bounty value is sufficiently large
   other miners may find it profitable to reorganize the chain to kill
   your block and collect the reward themselves. This is particularly
   profitable for larger, centralized, mining pools.

2) Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or
   SHA256^2 bounty may be diminished by the act of collecting it.

3) Due to limitations of the Bitcoin scripting language bounties can
   only be collected with solutions using messages less than 521 bytes
   in size.

4) "When Will We See Collisions for SHA-1?" - Bruce Schneier
   https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

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

- End forwarded message -

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


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Authenticated Time Synchronization

[Peter Todd]

On Tue, Sep 03, 2013 at 11:06:56AM +0200, Stephen Röttger wrote:

Sorry, for the late reply, I was out of town.

> > Specifically a client can generate a unique 128-bit nonce and have the 
> > trusted server timestamp it by signing a message including the nonce and 
> > the current time T. If the time between the request and the reply was dt, 
> > the actual time must be in the range (T, dt)
> > 
> > We can then extend this to an arbitrary number of clients with a merkle 
> > tree and one or more levels of untrusted servers. The servers combine all 
> > the nonces they receive in some time interval t into a merkle tree, then 
> > timestamp the digest of the tip of that tree. The clients then receive the 
> > merkle paths from the server, a proof of log2(n) size.
> I'm not sure if I understand you correctly. Do you mean that a time
> server will store the nonces of all requests from different clients in a
> given period and afterwards publish a merkle tree of these requests with
> a signed root node? I think this approach would have roughly the same
> computing overhead as our approach: one asymmetric signature per time
> period vs. one asymmetric signature per client and then ~2 hashes per
> time request vs. 3 in our approach.
> 
> > If a client doesn't trust the server at all, they know the time is within 
> > (T, dt); if they are willing to place some trust in the server the server 
> > can measure the interval between when they got the request and sent the 
> > proof, dt', and the client can take that into account for a more precise 
> > time. 
> If the server is not trusted, what prevents him from lying to the client
> and just forging some merkle tree in this case?

The idea is to allow multiple untrusted servers to assist a single (or
small number) of trusted servers so that the trusted servers don't have
to have the capacity to handle every client. The total computational
overhead isn't much different; the advantage is that the load can be met
by untrusted servers yet still give trustworthy times.

An example of this system could be for NIST to run a single trusted time
server that cryptographically signs time requests. Now Debian wants to
make it possible for Debian Linux installations to use trusted,
authenticated, NTP out of the box, but they themselves don't have the
resources to operate trusted servers with secure hardware and dedicated
administration. However they can procure plenty of untrusted server
capacity via cheap VPS hosting, and NIST is willing to let them connect
to the NIST trusted time server provided the Debian project doesn't make
more than, say, 100 requests a second.

Now, for all of the above, you can also think in terms of NIST operating
a *timestamping* service. Now what Debian is doing with their untrusted
servers is extending that one trusted timestamping service's capacity
with merkle trees - rather than timestamp the message directly,
timestamp n messages hashed into a merkle tree, and prove the timestamps
are real with the merkle paths to the trusted signature.

My observation, is that if you can get a nonce timestamped by an honest
timestamper the time on the timestamp must be the current time, modulo
easily measurable network delays. Is all this as accurate as traditional
NTP? No, but it's close enough for a lot of applications and it scales
really well.

Does that all make sense?

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


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Peter Todd]

On Sat, Oct 05, 2013 at 02:29:11PM +0200, Natanael wrote:
> 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.

Just make sure you sign your protocol revocation message using more than
one protocol...

Speaking of as a last ditch measure you can two messages that hash to
the same digest as a type of revocation message.

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


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bitcoin attack

[Peter Todd]

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


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NIST Randomness Beacon

[Peter Todd]

On Tue, Nov 12, 2013 at 10:10:13AM +0100, Adam Back wrote:
> (Top posted, so sue me, my text explains itself without the history).
> 
> Thats a big cc list.  I think you could create a beacon with bitcoin hash
> chain by having miners reveal a preimage for 6 old, consecutive blocks where
> the newest of the 6 old blocks is itself 6-blocks confirmed.  (ie reveal
> preimage on blocks 7-12.  The xor of those preimages defines a rolling
> beacon (new output every block, just with reference to blocks 7-12 relative
> to the current block depth).

A non-interactive approach could be to make use of random walks.

Suppose we want to create a single random bit from a single block hash.
Takethe right-most 127-bits, none of which are involved in the target
calculation, and calculate a random walk. If the sum of the walk is > 0,
call the bit a 1, and if < 0, call the bit a zero.

How much effort would it take to skew the probability distribution of
that one bit? The RMS distance after n steps is \sqrt(n), or about 11.3
in the case of 127 steps.(*) I'm handwaving here, but essentially we can
say that on average you'd need to select about 12 bits to have a decent
chance of forcing the bit to the value you want. But that takes 2^12
work, so even if you had 100% of the hashing power it's infeasible and
usually you'll have no control at all. (but sometimes you're block will
be the tie-breaker!)

*) Or 128 steps, and if the sum = 0, consider it a failed round and take
the next block instead.

A similar idea to other proposals for using "strengthening" of course,
but this has the advantage that we can make clear guarantees about
exactly what probability the attacker has of being able to influence a
given bit with however much hashing power. This also gives you options
to shape that probability distribution: a "closest wins" lottery using,
say, 256 sequential blocks to produce 64 bits, might want to assign more
bits to the walks for the MSBs of the random number, calculating them
from many blocks, than the LSBs which might take bits from only a few
blocks.

Anyway, it'd be interesting to develop the math for this idea more
fully.

-- 
'peter'[:-1]@petertodd.org
0003c3095cb8e7e25a516e8eef8314a20a2e68ab7df7d567a8db


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can we move to a forum, please?

[Peter Todd]

On Tue, Dec 24, 2013 at 10:33:08PM -0500, Bernie Cosell wrote:
> So that's not a handy archive.   But the first archive you mention is 
> great -- I didn't know it existed: it should be publicized or something.  
> I don't know if the RFCs permit it, but could there be a
> 
>   list-archive:
> 
> header?  It'd be out of the way but easy to find [and only a click away 
> in many eamil clients].

Maybe I'm missing some sarcasm, but just look in the headers of this
email:

List-Archive: 

> [but as a footnote, this one needs a search option -- how would you find 
> the posts in which we had discussed TDES?

mail-archive.com has a search function, and the "official" archive is
indexed by Google.

-- 
'peter'[:-1]@petertodd.org
0001ad53a6068118d04c32179c10e6a8717406158eba2433679a


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can we move to a forum, please?

[Peter Todd]

On Tue, Dec 24, 2013 at 07:43:12PM -0500, Greg wrote:
> I'm curious, is Aaron's response representative of the entire list's, or are 
> there folks out there lurking who would actually appreciate a forum?
> 
> Show of hands?

I mostly lurk and I strongly prefer a mailing list solution.

I'm in the Bitcoin community and we keep on talking about fully
decentralized backends to mailing lists/usenet replacements, but until
something like that is implemented, best to stick with the tried and
true mailing list. When something like that is implemented, it's gonna
look rather like a mailing list...

Mailing lists are great infrastructure: a pragmatic centralized core to push
messages around/moderate, and a whole host of decentralized
infrastructure around them like multiple archiving services and a wide
variety of client software to interface with.

I also note that it's a pain in the butt to PGP sign message board
posts, this is Cryptography after all...

-- 
'peter'[:-1]@petertodd.org
00026c4c027b8c680e2ff000b6b70bb10f70771b9a05868c613e


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can we move to a forum, please?

[Peter Todd]

On Tue, Dec 24, 2013 at 11:03:31PM -0500, Benjamin Kreuter wrote:
> > I mostly lurk and I strongly prefer a mailing list solution.
> > 
> > I'm in the Bitcoin community and we keep on talking about fully
> > decentralized backends to mailing lists/usenet replacements,
> 
> Out of curiosity, where do you see centralization in Usenet?  The only
> thing that comes to my mind are moderated newsgroups.

Moderation and spam control - both involve trusting centralized humans.

Keep in mind, this is Bitcoin we're talking about: we have very high
standards for what we call "decentralized". Equally we have very
suductive solutions to such distastful brushes with humanity in the form
of throwing proof-of-work, or better yet transferrable proof-of-work(1),
at the problem. Previously known as hashcash of course, but much more
usable this time around because there's actually a market for the stuff
in the form of Bitcoins so attackers don't have an advantage. Of course,
such pure solutions have real world drawbacks - like rich wankers
flooding your forums with junk because they can afford too - but they've
also never been tried in real-life so there's a lot of interest in doing
just that. Who knows if it'll actually work in practice, but all the
more reason to try.

In the meantime mailing lists are an excellent compromise.


1) https://en.bitcoin.it/wiki/Fidelity_bonds - Disclaimer: I invented
   them. Also "Just use fidelity bonds!" is a standard joke in the
   Bitcoin developer community, and for good reason.

-- 
'peter'[:-1]@petertodd.org
0001ad53a6068118d04c32179c10e6a8717406158eba2433679a


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can we move to a forum, please?

[Peter Todd]

On Tue, Dec 24, 2013 at 09:39:22PM -0500, Bernie Cosell wrote:
> *even*?  So it isnt' "just like" a mailing list at all.  Since I replied 
> to this post by hitting 'r' in my email client... and out it went.
> 
> I know PHPbb has gotten a lot fancier, but I still think that it is not 
> near as convenient as a mailing list.
> 
> [but I would vote strongly for having the list archived online!  That 
> makes searches of old threads and most every other 'benefit' of a forum 
> available while not messing up the ongoing discussion mechanism at all]

There's multiple archives of this mailing list, and starting you own is
trivial:

http://lists.randombit.net/pipermail/cryptography/
https://www.mail-archive.com/cryptography@randombit.net

IMO ease of archiving and ease of passing around archives is one of the
biggest strengths of mailing lists.

-- 
'peter'[:-1]@petertodd.org
00026c4c027b8c680e2ff000b6b70bb10f70771b9a05868c613e


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Can we move to a forum, please?

[Peter Todd]

On Tue, Dec 24, 2013 at 09:34:57PM -0500, Greg wrote:
> On Dec 24, 2013, at 9:02 PM, StealthMonger  
> wrote:
> 
> > Greg  writes:
> > 
> >> Also, do you enjoy not being able to edit your comments?
> > 
> > What kind of software do you suppose people are using, that might
> > interfere with editing comments?
> > Also, if you're so big on editing, why don't you edit your own postings?
> 
> We seem to be using the word "edit" completely differently.
> 
> I can't correct mistakes in an email that was sent.

Yes you can, reply to it and tell everyone what mistakes were in the
first one.

That history can be edited is a serious problem with webforums;
in the bitcoin community people keep talking about removing/changing the
edit functionality on bitcointalk.org to give cryptographic and
timestamped proof of what edits were made and by whome. It's been hacked
a few times now and there's doubt if the archives on the site are
accurate.

Mailing lists are much less succeptable to that problem, and fixing it
is much easier and can be done without anyone's permission - a good
thing.

-- 
'peter'[:-1]@petertodd.org
00026c4c027b8c680e2ff000b6b70bb10f70771b9a05868c613e


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Peter Todd]

On Fri, Jan 03, 2014 at 11:42:47AM -0800, coderman wrote:
> 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

Why can we only pick one?

In the context of stuff like email the overhead of n-of-m multisignature
isn't a big deal. Heck, even in the context of Bitcoin where
transactions have a cost per KB in the order of $0.10 to $1 n-of-m
multisignature is catching on as a way to protect funds from theft.

Why should digital signatures be any different?

-- 
'peter'[:-1]@petertodd.org
000251d8c6bb4f73d2f68e359fe143dfd3645374a4d26d09388c


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Timelock: time-release encryption incentivised by Bitcoins

[Peter Todd]

Timelock


Create a secret key that can be decrypted in a known amount of time
using parallel-serial hash chains. The creator can compute the timelock
in parallel, taking advantage of the large amount of cheap parallelism
available today, while others are forced to compute it serially,
constrained by the lack of scalar performance growth.

The chains are constructed such that Bitcoin addresses can be derived
from them and bounties placed, incentivizing third-parties to crack the
timelocks. This gives us a valuable chance to incentivize others to push
the envelope of scalar performance - important knowledge if we are going
to have any hope of knowing how soon our timelocked secrets will
actually be revealed! The Bitcoin secret keys and addresses are
constructed from the chains as follows:

iv ->  -> privkey -> pubkey -> secret -> hashed_secret

secret= SHA256(pubkey)
hashed_secret = RIPEMD160(secret)

Unlocking a given chain starting from the initialization vector gives
the person doing the work the private key, giving them an exclusive
opportunity to collect the bounty. Collecting that bounty forces them to
reveal the pubkey, from which the secret is derived. The hashed_secret
is then just a standard Bitcoin address, letting everyone see how large
the bounty is for unlocking the timelock.

Only a single algorithm - SHA256 - is supported by design: timelock
encryption works best if we're all on an even playing field.

Sourcecode: https://github.com/petertodd/timelock

Credit goes to Amir Taaki for helping develop the idea.


To make things interesting I've made a ~256 hour timelock with 32
chains, 8 hours per chain. The addresses associated are as follows:

1ERvMr5J8FETF7zj4QM98u8ZANaL1o9XGZ
18h7LwKpd9c6u8zJka3vMCASa8BfbiZFd4
1DBJDp57QmbigLEbUsFeqJT3mkArGzH3gv
1C1d6Tj7mZADurfj5yJ64p5BeRstquk7pu
1FsH58jnq5Kc6D7hb7vmUhjh8fwnijiWss
1PDwPYStrrkKpGtV2zX71XCDYL3E2g3KM7
1BF6oYLeTG7WxNWJjC8p4SHz62q7vgZhXX
1DxFiHr9ehVvi8JR2Cc5pcD4DEURUeFFda
1NKg3buX5BzhYgSY6Yvws9kMqZ6F1xnneD
1Kptov9sgDqQcavz1rVsuQvfi8PcQcL4rc
1P9k1HEfe3Z8LaiFejqsuDLjWXPZk1coDL
1Mw25mU89Wp2b9zyMCSnjAVQ7x4AVWx3sf
1B8gdbd1StpVnV99Few1ae1XXfKH6iry1D
13bisx8T42CzmFA2oAm1evEytcijrHJ2iR
1DyR6aNSbrJCzwqdeo9UN5obGR9L73Y2sa
1Fx7j3gU3q7bQdoni2zZhGQx7BnLt8xNeK
19q541m17opVcAxwisem7ak7YPuSpdS3Uj
1DYWzBpLBDd7fpta2JYLf7QZ7nAYiZiamR
13sZYBMdyzffwvCkzhGTu49pCGGR5C5B9v
1DFSjViJLTNhNj5wvsqRwoqPyR9UTAzLgW
13Zi9eawpkzZwRC8RgHJausQmUS4ECBzho
1BCQ5GVkAEzNYZ5WroAwXSspgpYfhQrojd
1K1gbE7qGLwbJDEoRyrCGxCsgJ4mHcFKwP
14Z4EawE1Kd3HRut43vWjgYUWYR3ZV5i2p
1NZTFVXVzKXvPMsFKZfkhZCBcbzqm7cGCj
1GFBBahQC5DzpLuJc6X1yVvvSKP2kCpUGf
184PkQFdzhPR3TjoCxddsNK7sr3DVVhJ45
14SLK5fXWdajoQZ2AX5WmAGbvRtLpdTgMq
1LagrzYykb8w4NveKrw2SDcpKMezwxX72Z
16XdtV2U3ksdhKkByRpiq3VN61aB62Ndgh
1Mu1SaUBu7aV4DHzEc4hxcgGzaYWdvuaAh
1EJWWxwZckP9eLS2VzgbUwqzxFDZKZcF9b

I've funded them with 10mBTC each, 320mBTC total. The full timelock
definition is as follows:

{
"chains": [
{
"algorithm": "sha256", 
"encrypted_iv": null, 
"hashed_secret": "1ERvMr5J8FETF7zj4QM98u8ZANaL1o9XGZ", 
"i": 0, 
"iv": 
"353b124909ec8774325d3f2f6b0a01c839e79e3ce687ee6e893310368afdf336", 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"495c6092c9004dc23c2deefb1db1deba88f8895a319f5d9f7ce8a53b2a9ecfe9", 
"hashed_secret": "18h7LwKpd9c6u8zJka3vMCASa8BfbiZFd4", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"8cbdf731374a71f22d59251890997ea001c2efa6e9c0bf808700c3d432ccf269", 
"hashed_secret": "1DBJDp57QmbigLEbUsFeqJT3mkArGzH3gv", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"bc4d75fa5ec8f28e121cd73806ce058e82036577130cffb3bd596f2aa59b2a7f", 
"hashed_secret": "1C1d6Tj7mZADurfj5yJ64p5BeRstquk7pu", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"80c622521c7aed318dac2b3c7d929e4e504d3c60650009b1abc0bae18fff979b", 
"hashed_secret": "1FsH58jnq5Kc6D7hb7vmUhjh8fwnijiWss", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"1ba76f9a694f987e1758dbc65cf104984dbe

Re: [cryptography] the Zcash Open Source Miner Challenge (and about Zcash in general)

[Peter Todd]

On Tue, Oct 11, 2016 at 03:34:33PM -, sten...@nymphet.paranoici.org wrote:
> Zooko Wilcox-OHearn  writes:
> 
> > https://z.cash ... There's a lot going on there. ... Jump in!
> 
> I want to jump in but I can't because z.cash has no mailing list.  A
> mailing list is needed because it allows participation by individuals
> for whom any low-latency Internet access, such as posting to the web,
> would allow them to be located and brought under political
> subjugation.  Their Internet utterances can only be by way of
> anonymizing remailers having long random latency and traffic mixing.

Additionally, mailing lists have robust infrastructure available for archiving
them by third-parties. This is important both to ensure that the historical
development record remains available, and to ensure that record is secure from
tampering.

Note how the Bitcoin Core project moved its mailing lists to the Linux
Foundation in part to ensure that discussion was happening on a forum whose
operators were unrelated to Bitcoin Core itself. Similarly day-to-day IRC
development chat happens on Freenode, again run by people distinct from Bitcoin
Core itself. I personally decided to stop posting new technical content on
bitcointalk and instead post it on the Bitcoin development mailing list years
ago for precisely these reasons.

I would strongly suggest that https://forum.z.cash/ be closed and replaced by a
mailing list. Warren Togami could help get it hosted by the Linux Foundation as
well if the Zcash project is interested in that hosting option.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography