Re: [cryptography] Message encryption standards?

[lodewijk andré de la porte]

Rot13 (or any other number) and many other pre-digital era message
encription methods. What is for you the advantage of this kind of
encription?

2011/5/10 Paul Crowley :
> Most standards that include encryption are to do with transport-level
> encryption (SSL, SSH, IPSec/IKE, WPA etc). However, OpenPGP, XML encryption,
> and CMS all offer a mode of operation more like this:
>
> - Bob sends Alice a packet that includes a public key for encryption
> - Offline, Alice can take this packet and a message and generate an
> encrypted message
> - The message reaches Bob by whatever means
> - Bob decrypts it
>
> Are there other standards of this shape that I've left out here?  Thanks!
> --
>  __
> \/ o\ Paul Crowley, p...@ciphergoth.org
> /\__/ http://www.ciphergoth.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] Point compression prior art?

[lodewijk andré de la porte]

Usage of the word rolling is also trademarked and limited.

You forgot about wheels that do not roll. Can't use that either.

You may have found some people using wheels for rolling. They should be
frowned upon, given extra-intimate pat-downs, blackmailed, arrested anyway,
made fun of before trial, given a long unfair trail, be non-lethally
tortured because they might know other "rollers" and later executed for
being a danger to the state beyond any help after which his familly will be
billed for all expenses (and exported).

Seriously.
On May 21, 2011 1:17 PM, "James A. Donald"  wrote:
> On 2011-05-21 9:12 AM, Paul Crowley wrote:
>> On 20/05/11 23:49, Nico Williams wrote:
>>> What about using Shcnorr's signature scheme with ECDH? Here's DJB
>>> talking about it in the context of his Curve25519, which uses the
>>> discard-y point compression technique:
>>>
>>> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>>>
>>> This would seem adequate to me, and should result in small signatures.
>>
>> I don't see how "discard y" works here. It works for DH because x(±yB) =
>> ±xyB = y(±xB). But for Schnorr the verifier needs sB-rnB and sB-rnB !=
>> sB-r(-nB). I guess it wouldn't be too expensive to try both - any
>> opinions on the patent status of that?
>
> I believe that the wheel is patented, as is the idea of trying to get
> around the patent by using something other than a wheel for the sort of
> purposes a wheel might be used for. Should someone ever figure how to
> make something other than a wheel roll, the idea of rolling non wheels
> is also patented.
>
> ___
> 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] D-Wave Sells First Quantum Computer

[lodewijk andré de la porte]

Any word on the kind of processing power this thing is? It really does sound
like the future, with it's supercooled processor 'n all. They state the
price is "consistent with large-scal,high-performance computing systems"
whatever that means, could it possibly be worthwhile?

>From wikipedia:

> *quantum annealing* (QA) is a general method for finding the global
> minimum  of a given *objective
> function * over a given
> set of *candidate solutions* (the *search space*), by a process analogous
> to quantum fluctuations 
> .


Which makes it quite usable, to my suprise.

In 30 years I'll have one at home. Not to worry.

Best regards,
Lodewijk


2011/5/27 James A. Donald 

> On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
>
>> I am among skeptics that quantum computers will break RSA1024 or ECDSA160
>> in the next 35 years, but maybe I have to revise my views.
>>
>>
>> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
>>
>>
>> On Wednesday, D-Wave Systems made history by announcing the sale of the
>> world's first commercial quantum computer. The buyer was Lockheed Martin
>> Corporation, who will use the machine to help solve some of their "most
>> challenging computation problems." ...
>>
>> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip, called
>> Rainier, representing the first commercial implementation of a quantum
>> processor. An early prototype, a 16-qubit system called Orion, was
>> demonstrated in February 2007. At the time, D-Wave was talking about future
>> systems based on 512-qubit and 1024-qubit technology, but the 128-qubit
>> Rainier turned out to be the company's first foray into the commercial
>> market. ...
>>
>
> 128 quantum bits sounds like a lot, but it is less than it seems, because
> this is not a general purpose quantum computer, though it can emmulate a
> general purpose quantum computer with considerably fewer quantum bits.
>
>
> ___
> 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] D-Wave Sells First Quantum Computer

[lodewijk andré de la porte]

This explaination is the first that really makes sense. Thanks.

(although there is future in quantum computing as in bits with >2 possible
values. This is not a "general computing" quantum computer.)

2011/5/28 Mark Avrum Gubrud 

> Lockheed will use the D-Wave device to conduct further "research" on
> contract to the USG (DoD, DHS, IC) under classification (D-wave is I believe
> a Canadian company) which will serve to further cover up its uselessness.
>  They may also use it to spice up marketing for their security services,
> since D-Wave is claiming they can use it to generate "software" for image
> recognition.  Lockheed can then say they make use of 'advanced quantum
> computing, an industry first, to generate algorithms for target
> recognition.'  That should certainly help do the trick when the customers
> are military, government and corporate bureaucrats and politicians.
>
> - Forwarded message from Jean-Philippe Aumasson <
> jeanphilippe.aumas...@gmail.com> -
>
> From: Jean-Philippe Aumasson 
> Date: Fri, 27 May 2011 12:24:24 +0200
> To: Crypto discussion list 
> Subject: Re: [cryptography] D-Wave Sells First Quantum Computer
> Reply-To: Crypto discussion list 
>
> Scott Aaronson's take on D-wave quantum computer and recent Nature paper:
>
> http://blogs.forbes.com/alexknapp/2011/05/24/q-and-a-with-prof-scott-aaronson-on-d-waves-quantum-computer/
>
> Excerpts:
>
> "they?re not claiming a ?quantum speedup? ? i.e., to solve some actual
> computational problem faster using quantum coherence.  They?re just
> claiming an observation of the sorts of quantum effects that would be
> a prerequisite to such a speedup"
>
> "researchers have constructed special examples of optimization
> problems where quantum annealing reaches the global optimum
> exponentially faster than classical simulated annealing.  But on the
> other hand, they?ve constructed other examples where quantum annealing
> is just as slow as classical simulated annealing, both of them getting
> trapped in local optima!"
>
> "any claims by D-Wave that the practical value of quantum annealing
> has already been demonstrated need to be taken with a huge grain of
> salt"
>
>
>
>
> 2011/5/27 lodewijk andr? de la porte :
> > Any word on the kind of processing power this thing is? It really does
> sound
> > like the future, with it's supercooled processor 'n all. They state the
> > price is "consistent with large-scal,high-performance computing systems"
> > whatever that means, could it possibly be worthwhile?
> > From wikipedia:
> >>
> >> quantum annealing?(QA) is a general method for finding the?global
> >> minimum?of a given?objective function?over a given set of?candidate
> >> solutions?(the?search space), by a process analogous to?quantum
> >> fluctuations.
> >
> > Which makes it quite usable, to my suprise.
> > In 30 years I'll have one at home. Not to worry.
> > Best regards,
> > Lodewijk
> >
> > 2011/5/27 James A. Donald 
> >>
> >> On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
> >>>
> >>> I am among skeptics that quantum computers will break RSA1024 or
> ECDSA160
> >>> in the next 35 years, but maybe I have to revise my views.
> >>>
> >>>
> >>>
> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
> >>>
> >>>
> >>> On Wednesday, D-Wave Systems made history by announcing the sale of the
> >>> world's first commercial quantum computer. The buyer was Lockheed
> Martin
> >>> Corporation, who will use the machine to help solve some of their "most
> >>> challenging computation problems." ...
> >>>
> >>> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip,
> >>> called Rainier, representing the first commercial implementation of a
> >>> quantum processor. An early prototype, a 16-qubit system called Orion,
> was
> >>> demonstrated in February 2007. At the time, D-Wave was talking about
> future
> >>> systems based on 512-qubit and 1024-qubit technology, but the 128-qubit
> >>> Rainier turned out to be the company's first foray into the commercial
> >>> market. ...
> >>
> >> 128 quantum bits sounds like a lot, but it is less than it seems,
> because
> >> this is not a general purpose quantum computer, though it can emmulate a
> >> general purpose quantum computer with considerably fewer quantum bits.
> >>
> >> ___
> >> 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
>
> - End forwarded message -
> --
> Eugen* Leitl http://leitl.org";>leitl http://leitl.org
> __
>

Re: [cryptography] D-Wave Sells First Quantum Computer

[lodewijk andré de la porte]

May I forumulate Lewis' first law:
As a discussion amoungst computer scientists continues the propability of
the P != NP problem being mentioned tends to to 1.

Or was this a law already? It seems familliar.

-Lodewijk "Lewis" André de la Porte
On May 29, 2011 4:25 AM, "Nathan Loofbourrow"  wrote:
> On Sat, May 28, 2011 at 7:05 PM, James A. Donald 
wrote:
>
>> On 28/05/11 03:37, James A. Donald wrote:
>>
>>> What can be said is that the class of problems soluble by a quantum
 computer
 is larger than the class of problems soluble by a classical computer.

>>>
>> On 2011-05-29 9:01 AM, David-Sarah Hopwood wrote:
>>
>>> No, it can't:
>>>
>>> - for idealized quantum and classical computers (with unbounded memory
>>> running for unbounded time), those classes are identical.
>>>
>>> - for quantum and classical computers that can be practically built at
>>> any
>>> point in time, and with a limit on the time to find a solution, it
>>> certainly isn't clear that the class of problems soluble by quantum
>>> computers will be larger (ever). That depends on how big and fast you
>>> can make quantum computers and classical computers.
>>>
>>
>> What can be said is that the class of problems soluble by a quantum
>> computer with a polynomially large number of components in polynomial
time
>> is larger than the class of problems soluble by a classical computer with
a
>> polynomially large number of components in polynomial time.
>
>
> Wait, was P!=NP proven and I missed it? I thought it was merely an
assertion
> with overwhelming evidence, but no formal proof.
>
> n
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digital cash in the news...

[lodewijk andré de la porte]

I get back from vacation and suddenly my inbox is filled with
misconceptions.

While this is supossed to be a fairly technical mailinglist (about
cryptography) it seems clear many people haven't quite understood bitcoins'
workings.

Let me break it down:
* With a private/public key combination you can sign a message stating
you're transferring a certain fraction of value (a bitcoin is what we call
the 1 value).
* This message you sent to nodes within the bitcoin network.
* Each node checks whether or not your transaction can be executed and
compiles these correct transactions into a 'block'.
* Each node will try to find a proof-of-work for the block he made. Once he
has it, he can ship the block off towards everywhere (as many as possible
other nodes).
* Recieving nodes will check the block and when they accept it, put a
reference (hash) to it in their next block. The resulting chain of blocks is
called the block 'chain'
Now that the transaction is solidified in a block one can proof he has some
amount of money, by referencing a payment to him in the block.

How do the first bitcoins enter the system? By making a block one gets an
award. The amount given per award is getting steadily lower. If you're
thinking you can get rich quick by letting your computer solve blocks, think
again! There's only one block to be solved every ten minutes, if it goes to
fast the blocks will get harder, and there's a lot of people trying to solve
it, you're electricity will likely cost you more than solving blocks is
going to earn you. You're welcome to try though, solving a block makes
transactions happen.

What will happen when the awards are nearly gone? Then the total amount of
bitcoins will stay nearly the same. This'll happen after quite some years.
The total amount will be nearly 21 million bitcoins. The transactions will
be paid for by bounty set on every transaction. As long as someone is
willing to make the proof-of-work your transaction will end up in the block
chain and be made permanent.

That is basically the system. The whole
whitepaperisn't long or hard to
understand and I highly suggest reading it.

I know of only two (not dealbreaking) issues:
1. Transactions take time to happen (they are non-instant) (bank
transactions are much worse though).
2. Because of the deflation all coins gotten earlier were easier to get and
are now "worth" as much a block gotten now. I prefer deflation over
inflation and if this really takes of the earliest of adaptors really
deserved the money.


On the (geo)economical side I think this is the best that every happend to
the world. The bitcoin is quite violent right now, because there's still so
little value being traded with them. But that will sort out and after that
it'll just keep on getting more stable. "Regular" currency's (dollars,
euro's, yen, whatever) are only as stable as their backing organisations or
resource. Anything that goes up has got to fall, and bitcoins aren't
anything, not even air! Trade has always been based on "when I give you
this, what can I do with what you give me back?" and so, when people accept
a certain amount of bitcoins for something, bitcoins have use and thus
value.

There is a wonderfull elegance in something we can trade at no costs,
without any ability to cheat or adversely manipulate it's amount. Even
without saying who (exactly) we are!

It's propable that when you swap something as elementary as our
not-wonderfull money with this it'll give some turbulance. And as with
anything new, especially when it gives true freedom, people will get their
panty's all up in a bunch. Usually their arguments either rest on not
understanding what's going on, or claiming that this gives a security issue.
The first argument I'll always counter with knowledge and logic. For the
second argument I'd like to parphrase Benjamin Franklin: "He who sacrifices
essential freedom for safety, deserve neither.". Surely being able to own
and transfer what you own is an essential  freedom.


I'd prefer not going into political conversation on here but I think it far
too interesting not to have it at all.

-- Lodewijk "Lewis" Andre de la Porte

2011/6/13 Nico Williams 

> On Mon, Jun 13, 2011 at 10:50 AM, Nathan Loofbourrow 
> wrote:
> > The good old market played a role here too. There are lots of investors
> > whose risk profile dictates that they should be in "safe" investments,
> e.g.
> > pension funds and old people. With the interest rates held on the floor,
> and
> > Greenspan and Bernanke sitting on their chest, those safe investors
> started
> > to buy up mortgages, because mortgages were big dumb investments and
> > everyone paid their mortgage.
>
> You just proved the point: the market was distorted, with private
> actors acting _within_ the distorted market parameters.  Thus people
> who needed to make low-risk investments did make what _seemed_ like
> low-risk investments (after all, real estate had been a low-risk
> investme

Re: [cryptography] Crypto-economics metadiscussion

[lodewijk andré de la porte]

I think chain mergers would be confusing for humans.

2011/6/14 Nathan Loofbourrow 

> On Mon, Jun 13, 2011 at 9:40 PM, Peter Gutmann 
> wrote:
>
>> Marsh Ray  writes:
>>
>> >I 'aint no self-appointed moderator of this list and I do find the
>> subject of
>> >economics terribly interesting, but maybe it would make sense to
>> willfully
>> >confine the scope of our discussion of Bitcoin and other virtual
>> currencies
>> >to the crypto side of it.
>>
>> Absolutely.  We need a virtual Perry.
>
>
> What if we created a peer-to-peer network for approving posts by
> timestamping approvals and hashing them into a chain of proof-of-work? Then
> we can all compete to moderate the list by application of CPU power.
>
> n
>
>
> ___
> 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 observation

[lodewijk andré de la porte]

I find the phrasing very strange. You cannot "destroy" a bitcoin, only
render it practically beyond recovery. You could still recover it by
figuring out which account's full of money and brute forcing their private
key from their public key and transaction log, it's not likely to be
feasable anytime soon though.

When someone incidentally loses his coins the same thing happens. Nothing
happens but the rarity of coins increases, due to there being less in
circulation. Speculating by destroying part of the goods is an ancient
practice, coffee traders did it too I believe. I also have a memory of a
movie in which a comic book collector is shredding most of a large pile of
comic books so they'll become rare and the remaining books are worth more.

Anyone with enough money should be able to do it, it'll be risky and
complicated but it could work. His "buying up the market" would have already
pushed the price very high and when his demand goes away everyone that still
has coins will be forced to sell them at a lower price. What's difficult and
different is that you don't actually need atomic units, you don't need 20mg
to make a cup of coffee. The current value determines what something's
worth.

In afterthought I do not think anyone could successfully do this in
any meaningful way.

Best regards,
Lewis

2011/7/6 Alfonso De Gregorio 

>
>
> On Tue, Jul 5, 2011 at 9:22 AM, Jon Callas  wrote:
>
> Good points. But nonetheless, it's a really, really cool property of the
>> system that you can gain by destroying bitcoins. I mean heck -- let's create
>> another sub-constant, H_s which is the constant that shows when it better to
>> destroy one than steal one. Obviously, if you have zero bitcoins, then
>> stealing them has some value. But heck -- what if you're sitting on a cache
>> of 371,000 coins. My intuition is that it's going to be better to destroy
>> than steal. If you're found with a stolen bitcoin, you have some 'splaining
>> to do. But if you silently destroy one -- then you see a market float.
>>
>
>
> Let's assume there is a way to convince market participants that some
> Bitcoins has been destroyed, what would happen then? The value of the
> current Bitcoin supply would slightly increase, that's correct.
>
> Would market participants be willing to invest more in order to secure
> their liquid assets against Bitcoin assassination attacks? How the attack
> rate would increase/decrease?
>
> The tragedy of the commons suggests us that when both risks and benefits
> are socialized between the elements of the population, individuals lack the
> incentive to unilaterally invest in security.
>
> On the other hand, as long as the reduction of money supply increases the
> value of the survived assets (ie, there's demand), some elements of the
> population will have an incentive to attack.
>
> It would be interesting to investigate further.
>
> Alfonso
>
> --
>  tweets @secYOUre  blog. http://Plaintext.crypto.lo.gy/
>
> ___
> 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 observation

[lodewijk andré de la porte]

I honestly don't see how. A transaction has an orgin, which is verified to
have the coins, and a destination, which is a public key that must have a
private key. AFAIK every public key has a computable private key
counterpart.

But please correct me.

2011/7/7 Taral 

> 2011/7/6 lodewijk andré de la porte :
> > I find the phrasing very strange. You cannot "destroy" a bitcoin, only
> > render it practically beyond recovery. You could still recover it by
> > figuring out which account's full of money and brute forcing their
> private
> > key from their public key and transaction log, it's not likely to be
> > feasable anytime soon though.
>
> As I said earlier, it is entirely possible *at the protocol level* to
> create transactions that transfer money into black holes that are
> unrecoverable -- no amount of crunch will recover them. None of the
> generally available interfaces expose this, however.
>
> --
> Taral 
> "Please let me know if there's any further trouble I can give you."
> -- Unknown
> ___
> 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 observation

[lodewijk andré de la porte]

I'm aware of the basic functionality of private-public key encryption. Brute
forcing possible private keys should eventually result in a specific public
key (seeing as how there's a limited set of private keys). I think it might
be possible to have public keys that no private key maps to, I'm not sure
however and it would also be hard to prove experimentally seeing how the
universe of private keys is quite large.
Also note that this kind of brute force attack isn't going to be feasible in
the near future. (however in 2100 it's likely an easy trick they teach in
high school's equivalent.)

Lewis

2011/7/8 Nico Williams 

> 2011/7/7 lodewijk andré de la porte :
> > I honestly don't see how. A transaction has an orgin, which is verified
> to
> > have the coins, and a destination, which is a public key that must have a
> > private key. AFAIK every public key has a computable private key
> > counterpart.
> > But please correct me.
>
> In some (most?) public key cryptosystems it's possible to prove that a
> valid public key has a corresponding private key (that is, there
> exists a valid private key for which the given public key *is* the
> public key).  That's used for public key validation.  It's not
> possible, however, to prove that the private key still exists.  Also,
> it's NOT possible to classically compute a private key from a public
> key -- when that is possible we say that the algorithm in question is
> broken :)
>
> 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] Is it possible to protect against malicious hw accelerators?

[lodewijk andré de la porte]

-You could perform a (very simple) software hash or something of the kind to
make the data sent to the HW accelerated thingy (performing difficult
operations) useless, that's less effective but it should work. Note that
this is in fact a new protocol and the applications are different.

-A better thing to do would be to build your own! After building a proper
open source community it'd be possible.

-Or use an FPGA to do the operations! It might give comparable performance
and you reflash your own "firmware" everytime you start it. It's general
purpose so it's unlikely to contain specific hacks.

Stay paranoid,
Lewis

2011/6/20 Jonathan Thornburg 

> I wrote
> > 2. If you don't trust the hardware, then you shouldn't use it.  Ever.
> >
> > It's really that simple: there's simply no way for software to be
> > safe in the presence of malicious hardware. :(
> >
> > Indeed, there's no way for software to *detect* malicious hardware. :(
> >
> > See, for example, the classic paper
> >   @inproceedings{1996-1849,
> > title={The Dark Side of "Black-Box" Cryptography, or: Should We Trust
> Capstone?},
> > booktitle={CRYPTO},
> > pages={89-103},
> > authors={Adam Young and Moti Yung},
> > year=1996
> > url = "
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.616&rank=1";
> >   }
>
> Sorry, that reference was a /dev/brain parity error on my part --
> while an interesting paper, it discusses something a bit different.
>
>
> > or the following brilliant rant by Henry Spencer from way back in the
> > 20th century:
> [[...]]
>
> This is the "right" reference, which I think nicely addresses the OP's
> question.
>
> Sorry for the mixup,
>
> --
> -- "Jonathan Thornburg [remove -animal to reply]" <
> jth...@astro.indiana-zebra.edu>
>   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
>   "Washing one's hands of the conflict between the powerful and the
>powerless means to side with the powerful, not to be neutral."
>  -- quote by Freire / poster by Oxfam
> ___
> 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 scalability to high transaction rates

[lodewijk andré de la porte]

This would revive many of the things people have aspired to kill with
bitcoins. Among others the "creation" of money (I can borrow and "store"
more money than I have). It would also mean moving the scalability problem
to a centralized system, a trusted party.

In other words: wouldn't having money backed by bitcoins instead of gold
essentially improve nothing?

I personally still worry about how big the early bird bonus was, someone
estimated the earliest of participators had a million of bitcoins. If
someone does then that'd grant him 1/21st of the worlds wealth (assuming an
insane surge in bitcoin usage), something I cannot quite believe anyone to
deserve. I mean it's possible, just not likely that anyone could be
responsible for 1/21 of the world's wealth.

Lewis

2011/6/17 James A. Donald 

> On 2011-06-17 4:35 AM, Sampo Syreeni wrote:
>
>> Since I've been forced to take yet another look into BitCoin and
>> algorithmic (high frequency) trading within a short timespan, I began to
>> wonder how they would work together. What precisely would happen to
>> BitCoin if we had tens to tens of thousands of high frequency traders
>> (thousands of transactions per second per trader) within the network?
>>
>
> The obvious next step is to have chaumian money and account money which has
> rapid low cost transactions, which money is converted into bitcoins at
> leisure, analogous to having gold, and account money and banknotes backed by
> gold.
>
> We should have accounts backed by bitcoins, and banknotes (chaumian money)
> backed by bitcoins.
>
> __**_
> 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 scalability to high transaction rates

[lodewijk andré de la porte]

There's currently a limited amount of transactions per block, this limit can
be changed. There's certain stuff in place to give bigger transactions,
older transactions and transactions with higher fee's precedence. That
should kill the possibility to truly DoS the network, although it's possible
to get blocks filled all the time, possibly forever. It's also possible to
DoS certain nodes, although the network will not likely suffer from it.
After sifting through all of this stuff the network seems quite inherently
robust. The only thing I worry about is when the amount of transactions
become too great for any single PC to manage, since a large part of the work
is done everywhere. Then all those pc's'll have to sync up, it's a data
nightmare. The block chain('s) will likely split and merge continuously. To
mine effectively the pools[1] might be the biggest mergers.
The optimizations suggested in the original whitepaper will have to have
been implemented. Actually thinking about it it shouldn't be THAT big a
problem.

Seems that bitcoins are one of the few things that make the future seem cool
again. After my dreams of spaceflight were destroyed by understanding of
physics :P.

- Lewis

[1] - mining pools are miners (hashers/signers for the blocks) that work
together in hopes of getting a more reliable income.

2011/7/22 Marsh Ray 

> On 07/21/2011 10:41 AM, Sampo Syreeni wrote:
>
>> HST is just an example of a mechanism which creates prodigious
>> amounts of transaction data. There are others, starting simply with
>> wide enough adoption of Bitcoin. So if the amount of transaction data
>> being shipped around can become a bottleneck here, it could indicate
>> a scalability limit on Bitcoin in more realistic situations.
>>
>
> That implies you suspect there may be a DoS attack against the Bitcoin
> network. I've heard this sentiment stated more explicitly from others,
> but haven't looked into it deeply myself.
>
> More often than not, distributed protocols have to go through multiple
> iterations of vulnerability and mitigation before they're really robust.
> Bitcoin even seems to have the added challenge of nodes being actively
> adversarial.
>
> OK I can't resist a quick look at the protocol spec. Searching...
>
> Hmmm. The page that currently "looks" the most comprehensive for the
> protocol description (on en.bitcoin.it/wiki) appeals to the original
> source release for its authority. Not a great sign.
>
> The protocol has a built-in script interpreter which must run to verify
> any transaction. But opcodes are being retroactively disabled! Like when
> "it was found that some of the arithmetic ones could be exploited to
> crash all Bitcoin nodes"
> https://forum.bitcoin.org/**index.php?topic=4723.msg68823#**msg68823
>
> E.g., OP_2MUL (multiply by 2) was disabled for "security reasons". (Hope
> you didn't accept any coin requiring it!) But they didn't disable the
> ability to add a number to itself. Will this be the next Callas
> Highlander operation?
>
> What if an attacker simply did a zero-sum exchanges of coins all day
> long, seeding crafted opcodes into a percentage of the circulating
> supply? Later, he could roll over his supply to "clean" coins and then
> disclose the vulnerability for those now being held by everyone else.
>
> Note that the script language includes a SHA-256 primitive opcode. What
> would be even more clever would be use the parasitic computation in the
> verification network as a mining cluster. Perhaps the results could be
> propagated back hidden in the distributed block database.
>
> All-in-all, this is not atypical for the evolution of a piece of network
> software, but some Bitcoin proponents seem to be attaching utopian hopes
> and/or hard cash value to this thing.
>
> Are there examples of other untrusted-peer distributed protocols
> maturing to become unassailably resilient for use across the wide internet?
>
> - Marsh
>
> __**_
> 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 scalability to high transaction rates

[lodewijk andré de la porte]

For a shipped product the ~5 minutes to a few hours delay isn't going to
matter much, since the product has to go through shipping first. Kinda like
buying an express shipment when you're not at home for the coming few weeks.

-Lewis

2011/7/22 Daniel Carosone 

> On Thu, Jul 21, 2011 at 08:47:35AM -0700, Nathan Loofbourrow wrote:
> > It's only when money is transferred
> > into our out of the exchange that a "real" transaction needs to be
> created,
> > whether though Bitcoin or through a bank. Private markets can help
> aggregate
> > small transactions.
>
> .. as well as help 'blind' these transactions to later log analysis
> (depending on what they do with their internal logs).
>
> > Of course, this presumes you trust the exchange, which is a different
> > matter.
>
> Indeed.  Note, however, an interesting convergence property here, for
> the practical user:
>
> Say I'm selling something on 'bitbay'.  Bitbay offers me two kinds of
> accounts: either immediate transactions to the bitcoin network, or an
> internal/affiliate 'Bitpal' account, with a running internal balance and
> aggregate external settlement transactions.
>
> I need to decide whether to trust the Bitpal exchange, both as a
> holder of credit and potentially also as a privacy-blinding service,
> presuming they claim to offer this value-add. Fine.
>
> However, in practice, both mean I need to wait some time for my money,
> even for the "immediate" transactions, until a sufficient consensus of
> conmation blocks comes in.  So on the face of it, there's little
> difference in my process for deciding when to ship my paid-for
> product.  The only way to make it go faster, where that matters, is to
> trust the exchange's internal accounts - that is the service they
> must offer.
>
> --
> Dan.
>
>
>
>
> ___
> 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] Diginotar broken arrow as a tour-de-force of PKI fail

[lodewijk andré de la porte]

The article itself is English (to my suprise, honestly) but if there's
any pheriferal information you'd like to have translation off, I'm
natively Dutch and wouldn't mind helping out.

Practically all Dutch government websites of any significance have a
Diginotar certificate. The government is stalling updates that block
Diginotar in hopes of not destroying consumer trust, although that
trust is misplaced. Under these is the DigiD project, which is
considered an equivalent to having a passport on the internet by the
Dutch government.

I wonder if hilarity will ensue.

Lewis

2011/9/6 Peter Gutmann :
> "Kevin W. Wall"  writes:
>
>>I don't read Dutch(?), but seems to have been pulled down. I saw it
>>yesterday. Was hoping to share it w/ some of my colleagues.
>
> It was updated after it was posted.
>
>>Do you have alternate URL?
>
> The current link from the reports page is:
>
> http://www.rijksoverheid.nl/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1.html
>
> If it moves again you can find it with this URL:
>
> http://www.rijksoverheid.nl/documenten-en-publicaties/rapporten/?keyword=diginotar&form-period-from=&form-period-to=&form-department=&form-information-type=rapporten
>
> Peter.
> ___
> 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 consequences of DigiNotar's failure

[lodewijk andré de la porte]

It is suggested that those that REQUIRE the security offered by SSL's party
verfication would have the knowledge to understand that SSL's party
verficiation CAN FAIL. And that those that have that require such a degree
of security could likely find something else.
The one who suggested the idea therefore assumes others assume SSL to be
broken by design, although that seems fairly obvious to me it's a big
suprise to many others. Such unclarity is dangerous and might lead/have lead
to sincere consequences, it might also not have. If it has then we are
unlikely to ever find out.

For those that do not understand my point take the following senario: I'm a
stupid person doing things others would kill me for. I know others want to
kill me for it so I hide it. I download Truecript and follow all the advice
there is on the subject, really figure out how to use it. Suddenly,
Truecript turns out to be broken (by design even), I didn't know or expect
it. Noone warned me. I am now hunted by those that wanted to kill me. Who is
to blame? Me for not knowing? Others for lying to me?
Truth be told it would be my fault, I should've known what I was doing. Yet
it would've been preferable if it would've been avoided.

TL;DR: Saying SSL is broken by design is true but still sad. Let's all get
over it and figure something better out.

Lewis

2011/9/17 M.R. 

> On 17/09/11 14:03, Peter Gutmann wrote:
>
>>
>> ... What you're saying is that no-one working in an
>>
>> environment where they actually need SSL should trust SSL.
>>
>
> I honestly don't understand why you would say "...where they
> actually need SSL...".
>
> Let's first assume we agree on what we mean by various terms here:
>
> That "environment" is one where people who are failed by
> their computer communication security system suffer consequences
> harsher (much, much harsher!) than a few hundred (or even a few
> thousand) dollars of a monetary loss, and where their adversary
> is a government unbridled by any need to subject their surveillance
> projects to an approval by an independent judiciary.
>
> "SSL" is a system that depends on the security on a large bunch
> of "trusted third parties", all of which are selected by various
> software vendors and any single one of them can completely subvert
> the security of the said communication system.
>
> It is obvious to me then that they ~don't need~ SSL; they should
> be instructed to ~avoid~ SSL. Or am I wrong in my understanding
> of what SSL is?
>
> Mark R.
>
> __**_
> 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] DigiNotar SSL Hack Diagram | Cyber Chatter

[lodewijk andré de la porte]

Mobile phones are mostly toys, and as such don't require solid security.
Until you use them to check you bank account that is. I doubt they'd ignore
that. The signing processes is likely only to have it be swallowed by
whatever 'secure execution' mechanism might be in place. I could be wrong
and they just figured the risks were negligible. They usually are, terms of
service usually include extensive non-liability.

Lewis

2011/9/20 Peter Gutmann 

> Marsh Ray  writes:
>
> >Those are the Cyanogen guys. Android modders.
>
> The same people who used a "publicly available private key" to sign their
> code.  Which, being publicly available to anyone, was promptly used by
> malware
> authors to sign *their* code.
>
> Reading through some of the Cyanogen threads, I get the impression they see
> security as a nuisance to be bypassed rather than a real requirement.
>
> Peter.
> ___
> 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, was Nirvana

[lodewijk andré de la porte]

The gold standard was fine as far as I know, as long as the gold flow was
steady. Gold isn't steady, Bitcoins totally are. Other than that I'd rather
trust in pet rocks* than in god and country, like US bills tell you to. If
you have any reason people should not use an unchanging coin without central
authority or requirement for trust, I'd REALLY like to hear it.

Lewis

*a much more accurate way to name the things we're trading here is "a
Bitcoin" or "Bitcoins" when used in multiple. Caps optional.

P.S.: I believe we've had discussions about Bitcoins before, this is a
crypto list but cypherpunk/application is also important.


2011/9/24 John Levine 

> >> Yet Bitcoin, nonetheless, works.
> >
> >How's BitCoin doing?
>
> As well as ever.  If you want an economy based on pet rocks, which is
> what bitcoins are, it works fine.  If you want an economy where people
> do the kinds of transactions they do with real money, not so great.
>
> Bitcoin's problems aren't the crypto, which as far as I can tell is
> quite sound.  Bitcoin has all the economic problems an 18th c. gold
> standard has, except that it's a lot easier to steal bitcoins than to
> steal gold bars.
>
> R's,
> John
>
> ___
> 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, was Nirvana

[lodewijk andré de la porte]

What I read in the history books (on
wikipedia)
is

> he main motivation for the third central banking system came from the Panic
> of 1907 , which caused renewed
> demands for banking and currency reform.

The Panic of 1907 being due to a "loss of liquidity"[1] and (not
suprisingly) "trust". "exacerbated by unregulated side
bets
 at bucket 
shops."
wikipedia states. That sounds an awefull lot like the complaints about top
bankers their bonuses. I cannot see what you mean with the part of history
you retold, and especially not how it maps to Bitcoin. You mention a
commodity backed system but the reasons for it failing are not the fact that
it's commodity based.

I should note that trust is not required by the Bitcoin system. And
liquidity's creation is limited, but the transfer of it cannot be. Any "lack
of liquidity" will be the result of people unwilling to invest wealth, like
it should be.

[1]  "an inelastic
 currency
and a lack of liquidity." was the weakness and cause of financial panics, so
it says.


Lewis

P.S.: I started writhing this before I did anything but I wasn't a trader in
the 18th and 19th century, I have no idea whether or not this is true:
No sane country would trade their goods for notes that promise you can get
gold, you want the gold itself after all. Not the bloody paper. The trust
that the paper could always be exchanged wasn't there, and that turned out
to be quite reasonable when the US's gold practically ran out (when?). We
decided to trust everything for convenience, and as long as we do there
really isn't any reason to complain. Even though the US has a dept that they
could never mint their way out of without losing global trust.

2011/9/25 John Levine 

> >The gold standard was fine as far as I know, as long as the gold flow
> >was steady.
>
> Um, no.  This isn't the place for a historic treatise, but the 18th
> and 19th centuries were one boom and bust after another, with lots of
> inflation and deflation, and not just because of new gold mines.  The
> reason the US created the Federal Reserve in 1913 is that unlike its
> European trading partners, we had a metal based currency and no
> central bank, which meant that the dollar was so unstable that trading
> partners refused to use it, and all foreign had to be denomated in
> pounds, francs, and occasionally marks.  The Fed was created in
> response to demand from the business and banking community to make the
> dollar more stable.
>
> > If you have any reason people should not use an unchanging coin
> > without central authority or requirement for trust, I'd REALLY like
> > to hear it.
>
> I can't force you to learn economic history if you don't want to.
>
> R's,
> John
>
> PS: Be sure not to confuse the stuff from the Ron Paul crowd with
> actual history.
> ___
> 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, was Nirvana

[lodewijk andré de la porte]

My words imply it has once "gone wrong". I have no knowledge of the gold
flow having messed with the gold standard significantly. I only hypothesize
it could go wrong (and subconsciously apply murphy's law).

Lewis

2011/9/25 James A. Donald 

> On 2011-09-26 5:13 AM, lodewijk andré de la porte wrote:
>
>> The gold standard was fine as far as I know, as long as the gold flow was
>> steady.
>>
>
> And when the gold flow was not steady, inflation and deflation was
> generally less than 1% a year.
>
> I conjecture that the expectation that value of the currency would remain
> stable in the long term stabilized the value in the short term - that when
> there was asset inflation, people started to prefer to store value in gold,
> and when there was asset deflation, people started to prefer to store value
> in other things, such as housing, whereas the present value of fiat money is
> destabilized by the fact that its future value could drop a great deal.
>
> __**_
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography>
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] -currently available- crypto cards with onboard key storage

[lodewijk andré de la porte]

Or pluk any old PC/laptop/notebook you have lying around and make it
talk over IP. Phones consume less energy though, nice idea. It's
arguably more secure than a CPU but I doubt it'd make a noticeable
difference (since the rest of the hardware needs to be secure also).

2011/10/28 Morlock Elloi :
> Take a cheap Android, write the code you need for it, make it talk via USB, 
> rip out all antennas, put it in your box (wrap in a paper bag first), and 
> connect with USB cable to the internal USB port.
>
> HW cost: $80
>
>
>> a Trojan. Security certification concerns put aside, the
>> architectural demands are no more elaborate than "a CPU
>> unlikely to be infected by a Trojan". From there, you either
>> pay for the certification gimmick, or you mend your own
>> solution. This is the basis for an "open source HSM" ...
>> cryptography mailing list
> ___
> 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] Declassified NSA Tech Journals

[lodewijk andré de la porte]

Personally, I think it's hilarious the "Extraterrestial Intelligence"
parts, about "how would other races try to contact us" haven't changed AT
ALL since then and this actually had some orgininal ideas. Like the
"controlled neutron bursts" for communication, that's actually extra
usefull because they cheat the lightspeed (maybe).

2011/11/27 Eugen Leitl 

> - Forwarded message from Marsh Ray  -
>
> From: Marsh Ray 
> Date: Sun, 27 Nov 2011 13:00:47 -0600
> To: Discussion of cryptography and related 
> Subject: [cryptography] Declassified NSA Tech Journals
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
>rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
> Reply-To: Crypto discussion list 
>
>
> Came across this on Reddit:
>
> Declassified NSA Tech Journals
> http://www.nsa.gov/public_info/declass/tech_journals.shtml
>
> It all looks so interesting it's hard to know where to start.
>
> - Marsh
>
> * Emergency Destruction of Documents - April 1956 - Vol. I, No. 1
> * Development of Automatic Telegraph Switching Systems - July 1957 - Vol.
> II, No. 3
> * Chatter Patterns: A Last Resort - October 1957 - Vol. II, No. 4
> * Introduction to Traffic Analysis - April 1958 - Vol. III, No. 2
> * Signals from Outer Space - April 1958 - Vol. III, No. 2
> * Science and Cryptology - July 1958 - Vol. III, No. 3
> * Net Reconstruction - A Basic Step in Traffic Analysis - July 1958 - Vol.
> III, No. 3
> * Weather; its Role in Communications Intelligence - July 1958 - Vol. III,
> No. 3
> * A New Concept in Computing - December 1958 - Vol. III, No. 4
> * About NSA - January 1959 - Vol. IV, No. 1
> * Antipodal Propagation - January 1959 - Vol. IV, No. 1
> * Data Transmission Over Telephone Circuits - January 1959 - Vol. IV, No. 1
> * Soviet Science and Technology: Present Levels and Future Prospects -
> January 1959 - Vol. IV, No. 1
> * Cryptanalysis in The German Air Force - April 1959 - Vol. IV, No. 2
> * The Special Felix System - April 1959 - Vol. IV, No. 2
> * Intercept of USSR Missile Transmissions - July 1959 - Vol. IV, No. 3
> * A Program for Correcting Spelling Errors - October 1959 - Vol. IV, No. 4
> * COMINT Satellites - A Space Problem- October 1959 - Vol. IV, No. 4
> * The Borders of Cryptology - October 1959 - Vol. IV, No. 4
> * Did Aleksandr Popov Invent Radio? - January 1960 - Vol. V, No. 1
> * Bayes Marches On - January 1960 - Vol. V, No. 1
> * Book Review: Lost Languages - Fall 1960 - Vol. V. Nos. 3 & 4
> * The "Tunny" Machine and Its Solution - Spring 1961 - Vol. VI, No. 2
> * The GEE System I - Fall 1961, Vol. VI, No. 4
> * Book Review: Lincos, Design of a Language for Cosmic Intercourse, Part 1
> -
>  Winter 1962 - Vol. VII, No. 1
> * A Cryptologic Fairy Tale - Spring 1962 - Vol. VII, No. 2
> * Aristocrat - An Intelligence Test for Computers - Spring 1962 - Vol.
> VII, No. 2
> * Why Analog Computation? - Summer 1962 - Vol. VII, No. 3
> * German Agent Systems of World War II - Summer 1962 - Vol. VII, No. 3
> * The GEE System - V - Fall 1962 - Vol. VII, No. 4
> * How to Visualize a Matrix - Summer 1963 - Vol. VIII, No. 3
> * Book Review: Pearl Harbor: Warning and Decision - Winter 1963 - Vol.
> VIII, No. 1
> * Soviet Communications Journals as Sources of Intelligence - August 1964 -
> Vol. IX, No. 3
> * Use of Bayes Factors With a Composite Hypothesis - Fall 1964 - Vol. IX,
> No. 4
> * A List of Properties of Bayes-Turing Factors - Spring 1965 - Vol. X, No.
> 2
> * A Boer War Cipher - Summer 1965 - Vol. X, No. 3 and Fall 1965 - Vol. X,
> No. 4
> * Something May Rub Off! - Winter 1965 - Vol. X, No. 1
> * Time Is - Time Was - Time Is Past Computes for Intelligence - Winter
> 1965 - Vol. X, No. 1
> * The Apparent Paradox of Bayes Factors - Winter 1965 - Vol. X, No. 1
> * Extraterrestrial Intelligence - Spring 1966 - Vol. XI, No. 2
> * Some Reminiscences - Summer 1966 - Vol. XI, No. 3
> * Communications with Extraterrestrial Intelligence - Winter 1966 - Vol.
> XI, No. 1
> * The Voynich Manuscript: "The Most Mysterious Manuscript in the World" -
> Summer 1967 - Vol. XII, No. 3
> * Weather or Not - Encrypted? - Fall 1967 - Vol. XII, No. 4
> * The Library and the User - Spring 1968 - Vol. XIII, No. 2
> * Mokusatsu: One Word, Two Lessons - Fall 1968 - Vol. XIII, No. 4
> * Key to The Extraterrestrial Messages - Winter 1969 - Vol. XIV, No. 1
> * Curiosa Scriptorum Sericorum: To Write But Not to Communicate - Summer
> 1971 - Vol. XVI, No. 3
> * Multiple Hypothesis Testing and the Bayes Factor - Summer 1971 - Vol.
> XVI, No. 3
> * The Rosetta Stone and Its Decipherment - Winter 1971 - Vol. XVI, No. 1
> * Writing Efficient FORTRAN - Spring 1972 - Vol. IX, No. 1
> * The Strength of the Bayes Score - Winter 1972 - Vol. XVII, No. 1
> * Q.E.D. - 2 Hours, 41 Minutes - Fall 1973, Vol. XVIII, No. 4
> * Rochford's Cipher: A Discovery in Confederate Cryptography - Fall 1973,
> Vol. XVIII, No. 4
> * Earliest Applications of the Computer at NSA - Winter 1973 - Vol. XVIII,
> No. 1
> * Addendum to "A Cryptologic

Re: [cryptography] Law of unintended consequences?

[lodewijk andré de la porte]

I figured it'd be effective to create a "security awareness group" figuring
the most prominent (and only effective) way to show people security is a
priority is by placing a simple marking, something like "this site isn't
safe!" and contacting the owners with what the exploit is. That'd also
provide challenge to those who participate and it doesn't hurt anyone. I
think it's most likely a mind-spinoff of lulzsec's work, who took it to the
extreme.

It kind of shocked me that regardless of the good spirit of my idea, the
image of a happy hacker talking about how amazingly well he pulled off some
hack and another about the stimulating it is to work with people who "live
for it", would also be utterly illegal! I kinda liked the fact that the
Internet was like a wild west, law is local and everything is possible and
permitted. It being digital people wouldn't get quite so hurt if things
went wrong. Now with security and size came legal matters. The funny thing
to observe is that those who bring in the law have no idea of what's going
on, they are (literary!) from another world! But with there laws the first
thing they banned were the vigilante's, the criminals are still there. Some
aren't building fences because the police will come busting everyone who
passes into their backyard anyway, people become defenseless!

Let's hope we get to keep enough of our freedom to do things wrong. Let's
prevent ignorance with danger.

-Lewis

2011/12/7 ianG 

> On 7/12/11 13:47 PM, Benjamin Kreuter wrote:
>
>> On Tue, 6 Dec 2011 12:34:37 +0100
>> Adam Back  wrote:
>>
>>> Kids figure this stuff out getting through site restrictions on
>>> school wifi also.  Some schools try to block popular web games.. eg
>>> runescape.
>>>
>> Let us not discourage either the children or the schools!  This sounds
>> like an excellent way for children to pick up some technical skills
>> and to learn about computer security.  If we must condition our
>> children to think that censorship is the norm, at least we can also
>> provide them with some decent education in the process.
>>
>
> Yes.  One of the unpleasant side effects from the western tendency to
> demand solutions from politicians - make hacking illegal - is that it has
> allowed a generation of programmers and businesses to dumb-down security,
> making them more vulnerable to hackers who don't respect the law.
>
> So if anything it's just caused the outsourcing of the hacking business to
> places east of Europe, and the increase in profits potential.
>
> Oh well.  I suppose the market cap for facebook and google justifies it.
>
> iang
> __**_
> 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 are expired code-signing certs revoked?

[lodewijk andré de la porte]

I'm afraid signing software is multiple levels of bullocks. Imagine a user
just clicking yes when something states "Unsigned software, do you really
want to install?". Imagine someone working at either a software or a
signing company. Imagine someone owning a little bitty software company
that's perfectly legitimate and also uses the key to sign some of his
maleware.

Software signing isn't usable for regular end users, experienced users
already have hashes to establish integrity up to a certain level, guru's
and security professionals compile from source instead of trusting some
binary. And yes that does exclude hidden-source software, it's the only
sensible thing to do if you don't want trust but real security!

-Lewis

2011/12/7 Jon Callas 

>
> On 7 Dec, 2011, at 11:34 AM, ianG wrote:
>
> >
> > Right, but it's getting closer to the truth.  Here is the missing link.
> >
> > Revocation's purpose is one and only one thing:  to backstop the
> liability to the CA.
>
> I understand what you're saying, but I don't agree.
>
> CAs have always punted liability. At one point, SSL certs came with a huge
> disclaimer in them in ASCII disclaiming all liability. Any CA that accepts
> liability is daft. I mean -- why would you do that? Every software license
> in the world has a liability statement in it that essentially says they
> don't even guarantee that the software contains either ones or zeroes. Why
> would certificates be any different?
>
> I don't think it really exists, not the way it gets thrown around as a
> term. Liability is a just a bogeyman -- don't go into the woods alone at
> night, because the liability will get you!
>
>Jon
>
> ___
> 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 are expired code-signing certs revoked?

[lodewijk andré de la porte]

I'm afraid "far more effective" just doesn't cut it. Android has "install
.APK from third party sources" which you'll engage whenever you install an
APK without using the market, trusted or not. You can just put you malware
on the market though, they can then pull it back off 'n all but just
package it in "Sexy asian girls #1283" and the like with different accounts
everytime. You're still in a bit of a sandbox though, can't help that
(although some do say it's not worth that much).
The appstore has heavy code review (so they say) that'd prevent malware
from entering the appstore, so far so good, it also prevents some
legitimate and a whole lot of questionable stuff. So people invented Cydia.
I never used it and I sure as hell didn't check it security features, but I
think you see where this is going.

Naturally, as with all security, implementation matters a lot. I'm not
saying I'm against signing stuff, I'm just saying I don't think it ever
helped me.

Op 8 december 2011 02:54 schreef Marsh Ray  het
volgende:

>
> On 12/07/2011 07:01 PM, lodewijk andré de la porte wrote:
>
>> I figured it'd be effective to create a "security awareness group"
>> figuring the most prominent (and only effective) way to show people
>> security is a priority is by placing a simple marking, something like
>>  "this site isn't safe!"
>>
>
> I thought the international symbol for that was already agreed upon:
> goatse.cx
>
>
>
> On 12/07/2011 07:13 PM, lodewijk andré de la porte wrote:
>
>> I'm afraid signing software is multiple levels of bullocks. Imagine a
>>  user just clicking yes when something states "Unsigned software, do
>> you really want to install?".
>>
>
> You're just thinking of a few code signing schemes that you have direct
> experience with.
>
> Apple's iPhone app store code signing is far more effective for example.
>
>
>  Imagine someone working at either a
>> software or a signing company. Imagine someone owning a little bitty
>> software company that's perfectly legitimate and also uses the key to
>> sign some of his maleware.
>>
>
> His own malware? With his own certificate? How dumb can he be?
>
>
>  Software signing isn't usable for regular end users, experienced
>> users already have hashes to establish integrity up to a certain
>> level, guru's and security professionals compile from source instead
>> of trusting some binary. And yes that does exclude hidden-source
>> software, it's the only sensible thing to do if you don't want trust
>> but real security!
>>
>
> A scandal broke just the other day when http://download.cnet.com/ was
> found to be trojaning downloaded executables in their custom "download
> manger" wrapper. Just to be helpful, this wrapper would change your home
> page to Microsoft, change your search engine to Bing, and install a browser
> toolbar that did lord knows what other helpful stuff if you were dumb
> enough to click the "Yes please install the helpful thing I downloaded"
> button. After the find their PC filled with crapware, users likely
> attribute it to the poor unsuspecting developer of the legitimate
> application they'd intended to download.
>
> Even the simplest code signing mechanism at least prevent application
> installers from being corrupted by commercial distribution channels like
> that. But only IF enough users were given a security justification for
> insisting on a valid signature on the installers that CNET would recognize
> that that kind of sleazy practice it would harm their brand.
>
>  http://download.cnet.com/8301-**2007_4-57338809-12/a-note-**
>> from-sean-regarding-the-**download.com-installer/<http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/>
>>
>
> MS Windows 8 is said to be introducing an app store distribution channel.
>
> - Marsh
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How are expired code-signing certs revoked?

[lodewijk andré de la porte]

To which I retorted that it we want to install from other sources, and then
it'll lose it's value. Cydia is commonly used and (I just checked) is a
package manager with repository's like any other package manager, no
sandboxing. I'd say that by locking up the appstore Apple gave away any
control it could have over third party software.

But yeah, your right. Code signing does have good use for the appstore.

Op 8 december 2011 03:26 schreef Marsh Ray  het
volgende:

> On 12/07/2011 08:12 PM, lodewijk andré de la porte wrote:
>
>> I'm afraid "far more effective" just doesn't cut it. Android has
>> "install .APK from third party sources" which you'll engage whenever you
>> install an APK without using the market, trusted or not.
>>
>
> That's why I didn't use Android as an example.
>
> I said "Apple's iPhone app store code signing is far more effective".
>
> - Marsh
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] CAPTCHA as a Security System?

[lodewijk andré de la porte]

>
> Would a security system that does not model a human attacker really
> qualify as a security system?
>

If it's man-controlled it certainly does, like a ballistic missile blocking
device is also security/safety.

In real life security is also an "analog" kind of thing. Something becomes
"more secure". Passwords (at any complexity) always have a chance to be
random guessed, yet they're security. Bottom line security is usually
considered to be something of "added safety".

The foolish thing here was to think it'd really help. Yet other will always
be so foolish to misunderstand what CAPTCHA's mean and meant.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] CAPTCHA as a Security System?

[lodewijk andré de la porte]

I'd like to add to this conversation, as a side note, that a new type of
security has (fairly) recently emerged: legal security. "It's illegal to
break in, so we don't need security". Quite common in convenience stores,
people's homes and now, the Internet. Some will find that this sort of
security sucks. That it doesn't protect them very well. They won't care
though, because even though the window was open, no one should've entered.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Password non-similarity?

[lodewijk andré de la porte]

The reason for regular change is very good. It's that the low-intensity
brute forcing of a password requires a certain stretch of time. Put the
change interval low enough and you're safer from them.

We've had someone talk on-list about a significant amount of failed remote
ssh login attempts. Should he chose not to force user to change their
passwords they wouldn't. And the likelyhood of a successfull login
would improve with the years (given coordination) to somewhere above the
admin's comfort zone.

The timeframe in which a password has to change also limits the maximum
time exposed once someone has cracked it. This is relevant when the
adversary needs multiple opportunity's to coincide. The amount of time
it'll have access without triggering resource-counting or other
"suspicious behavior" alarms becomes limited, as changing a password would
either lock him or the legitimate user out.

For most systems though, it's a complete waste of time.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] CAPTCHA as a Security System?

[lodewijk andré de la porte]

>
>
> My neighborhood Wal*Mart has pretty much eliminated cashiers in favor of
> self-checkouts.
>
> Anyone so inclined could walk in, load up a cart, walk up to a
> self-checkout, check maybe half the items in the cart, pay for them and
> leave, with no one the wiser until the physical inventory didn't match up
> with the computer inventory.
>
> Wal*Mart is not stupid.   They know full well that a certain percent of
> shoppers will indeed walk out with a certain amount of goods, every day.
>
> They have a very good idea of the dollar value of this "shrinkage", and
> they have decided that the shrinkage costs less than the eight or so
> dollars an hour that it would cost to put clerks in place.
>

Our cozy dutch supermarkets are trying self-checkout systems themselves.
They sometimes check carts with what's scanned. My dad's theory was that
people are so afraid to have forgotten that they'd most likely scan their
products multiple times more often than they forgot, and that relatively
little people steal anyway.

The self-checkouts are also faster, and thus more convenient. Not to
mention more consistent, even on holidays they'll work.

The vector on security is getting thinner though. Although this is
certainly connected to not needing security, mostly due to legality. You
seem to agree. Good. Crypto list. Right. Sorry.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Password non-similarity?

[lodewijk andré de la porte]

2012/1/3 Jonathan Katz 

> On Mon, 2 Jan 2012, lodewijk andré de la porte wrote:
>
>  The reason for regular change is very good. It's that the low-intensity
>> brute forcing of a password requires a certain stretch of time. Put the
>> change interval low enough and you're safer from them.
>>
>> We've had someone talk on-list about a significant amount of failed remote
>> ssh login attempts. Should he chose not to force user to change their
>> passwords they wouldn't. And the likelyhood of a successfull login
>> would improve with the years (given coordination) to somewhere above the
>> admin's comfort zone.
>>
>
> I just don't buy this argument; am I missing something?
>
> Say passwords are chosen uniformly from a space of size N. If you never
> change your password, then an adversary is guaranteed to guess your
> password in N attempts, and in expectation guesses your password in N/2
> attempts.
>
> If you change passwords constantly, and an adversary guesses a random
> password (with replacement) each password-guessing attempt, then in
> expectation the adversary guesses your password in N attempts. Not much of
> an advantage.
>

Yes it only doubles the security. I hate admitting I overestimated
something. It looks better on paper though, infinite maximum. And it still
limits time exposed on breach, which may be useful but likely isn't. Nope.
I can't really think of why it'd substantially help. Twice could be good,
but a single character would do that too. Ugh.

Time to rage on anyone who stupendously uses password timeouts.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bitcoin in endgame

[lodewijk andré de la porte]

2012/2/23 Moritz Bartl 

> On 23.02.2012 10:24, Eugen Leitl wrote:
> > In general so far I fail to see the validity of most criticisms
> > against BitCoin. So far I see the only real problem is government
> > crackdown on exchanges, which only makes BTC free-floating
> > and slows down the growth of the underlying economy.
> >
> > Sorry if this is off-topic to cryptography. We can take the
> > thread offlist at any time.
>
> This was an offtopic discussion from the start. The original paper does
> not include anything about crypto.
>
> Anyway, the problem you mention is exactly the one described in the paper.
>
> "Using Mancur Olsen's rationale that a prince is a bandit that stops
> roving, the notion of the mining franchise being captured by the botnets
> might have been an acceptable compromise to the economy growing up
> around bitcoin mining, if it went no further [Olsen].  However,
> criminals are rarely satiated.  Several things happen: (a) incentives
> for easy money naturally cause an increase in criminal participation at
> all levels, such as direct theft of bitcoins.  This increase across the
> board encourages (b) honest users to pack up and leave.  Both of these
> effects combine to create rising criminality, and (c) at some stage the
> Feds get involved.  Finally, (d) the system collapses."


So "criminals" exist and they want to make money (which they already could
but now they want more).  Now something happens that summons an unbeatable*
nemesis/third party and everything goes to hell.
Nice line or reasoning. Very certain, unbiased, etc.
Funny thing is that everyone believes them because they can use LaTeX, put
references (to websites, most of which are bullocks themselves) and call it
a paper. It's just another rambling about something that could but really
won't happen.

Don't forget to put things into perspective.

*can't really beat anything, they can only make it crime-exclusive. (you
make it illegal and only those that don't care about the law can use it.)
___
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"

[lodewijk andré de la porte]

>
> That's it!  Now, leave aside the libertarian hopes and the politics and
> the freedom bias and right to code and the "this time it's different" and
> all that crap -- and ask yourself.
>
> Where do you want to invest your future?
>

I will invest my time and skill to improve the people's knowledge
and sovereignty. For the sake of brevity I will omit my reasons to do so.

I find that in a capitalist society everything starts with money. Anything
will have finances in it's foundation. If we are to create anything pure,
elegant and satisfying we've can't have shaky foundations; we can't have
bad money. Improving money will improve everything.

Whether or not Bitcoins can do it, I can't be sure. I think it has the
potential to. What better way to spend our time than to try and make it so?

Thank you for the e-mail iang. I very much appreciate it.
___
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"

[lodewijk andré de la porte]

>
> > 1. No offline transactions, which makes Bitcoin useless for
> > a large class of transactions.
>
> On Mon, 27 Feb 2012, James A. Donald wrote:
> > Smartphones.
>
> The implicit assumptions here, namely that
> * everyone who wants to make financial transactions carries a smartphone
> * smartphones never break down
> * smartphone batteries never run down
> * smartphones always have network connectivity
> don't always hold.
>
I feel obliged to note that anyone carring an up-to-date wallet file can
permit and validate transactions. If his/her wallet file is out of date
double spending might occur, even then one might apply trust to still do
transactions.


> [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.]

Working on this. And the network problem.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Bitcoin-mining Botnets observed in the wild? (was: Re: Bitcoin in endgame

[lodewijk andré de la porte]

>
> =
> The only permanent solution is advocating to politicians for more
> international legislation and laws to be passed for more involvement
> between cyber security professionals and federal law-enforcement agencies.
> Sinkholing is a temporary solution but finding the groups behind the
> botnets and allowing law enforcement to apprehend them is the only
> permanent solution to the problem. New regulations will give more
> jurisdiction to execute the following countermeasures:
>
>Carrying out mass remediation via a botnet
>Using the expertise and research of private companies, providing them
> with warrants for immunity against cybercrime laws in particular
> investigation
>Using the resources of any compromised system during an investigation
>Obtaining a warrant for remote system exploitation when no other
> alternative is available
>
> After the taking down the old Hlux we asked your readers on securelist.comhow 
> Kaspersky should proceed with the botnet: The answer was quite clear:
> Only 4% voted for “Leave the botnet alone.”. 9% agreed with “Keep the
> sinkholing up and provide IP address logs to the appropriate contacts so
> they can take actions.” and 85% voted for “Push a cleanup tool that removes
> the infections.”. In this poll 8539 votes were counted.
> ===
>
I actually really like this advice. I'd even take it a step further, remove
all cybercrime laws. Crazy? Maybe. But I'd really love the Internet to turn
back to the wild west it once was. Sure people will get robbed and it'll
act as a catalyst to horrible people. But it'll always enable everyone at
least as much as the horrible people. Subsequently the people can safeguard
the others. We could, by necessity, create *actually secure* systems.
Crazy, I know.
 The researchers said that security companies are informing Internet
service providers about the infections, but cannot legally take direct
action to clean up the machines. 

 But "there is one other theoretical option to ultimately get rid of
> Hlux," Ortloff wrote. "We know how the bot's update process works. We could
> use this knowledge and issue our own update that removes the infections and
> terminates itself. However, this would be illegal in most countries."

Once again proving cybercrime-laws are the only real cybercrime.

The security company people told the Ars Technica reporter that they
>> were surprised that the Botnet operators didn't try to recover control
>> of the bots.
>
> (If I was them, I'd be worried about backtracking.  Once I knew I was
> under attack, I would prefer to cut & run rather than reveal.)

And given that the botnet's low size and thus low profit.


Good observations and calculations.  So, let's say you wanted a botnet to
> do mining.  What could you do to improve that?

Get a bigger network! Targeting gamers would also help, given their
hardware.

In short:
1) Virality. Make it spread like the worst wildfire you can imagine. No
remorse, no half measures.
2) Stealth. Be hard to notice (don't use all resources). Evade antivirus
software in rigorous manners. Anything goes. Fake drivers, emulated OS,
intermix with legitimate services (protip: stolen opensource games,
fake/infected scene releases), anything.
Don't forget that most users don't care, and couldn't even if they tried.
They will run, with admin rights, anything they think is trustworthy, and
they're pretty trusting. Intermix with legitimate (but stolen and
rebranded) would be fairly good. That'd even allow advertisements to be
bought for them.

Performance is nodes*avg_node_performance. Either target better nodes, or
more of them.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Doubts over necessity of SHA-3 cryptography standard

[lodewijk andré de la porte]

>
> But as SHA-2 is still a pure Merkle–Damgård construction it deviates
>>  from an ideal pseudorandom function or random oracle in a couple of
>> ways.
>>
>> Firstly, and most significantly, it is subject to length extension
>> attacks. This means that given a hash value of some secret message,
>> we can compute the hash value of that message with our own chosen
>> plaintext appended without needing to know the original message. This
>> is surprising to many protocol designers!
>>
>
>
> Well, that's a surprise to me.  But on reflection, the reason it is a
> surprise that I (we?) never considered that feature is because we would
> never ever rely on it.  It's like saying, oh, gosh, we can use SHA1 to
> protect against buffer overruns!  Happy Days!
>
> More vitally it allows people that've heard and the hash of the message
"Give:john:coin:20" to create AND SIGN the message
"Give:john:coin:2000". It's a bit of an unusual attack though,
especially since we usually have length fields. It could push other data
out of the message though. It really depends on the protocol. I certainly
scratched behind the ears when I read this. There was a paper on authentic
cookies without server side state: take the cookie's content, append a
secret, hash it and put the hash after the rest of the cookie. If you put
data in a sort of URL-encoded manner into the cookie that creates a large
potential threat.

My understanding is that the SHA-3 finalists address these issues.
>>
>
> Meanwhile, notwithstanding excitement nearly a decade ago now, SHA1
> still chugs on.  And software engineering's got your back.
>
> That's not to say that the SHA3 comp was unneeded.  But it wasn't the
> same level of necessity that AES had.


I wasn't around for that competition. SHA3 certainly isn't "urgent" for the
industry, if they need more security they usually just enlarge n (more
bits) and it'll quickly suffice. Being proactive is very nice though.
Adaptation of anything is usually really slow. Having SHA3 around in a
tested and production ready state will increase our security more than it
has to? Great.

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

Re: [cryptography] ��

[lodewijk andré de la porte]

Cut all messages in small parts. Onion route them around a little. Send
random messages a random place every so often. This would still likely
expose conversations and other high level analysis.

For more vital purposes one could use continuous datastreams and
occasionally put a packet in there. In fact we could have these on every
link without much trouble (tons of trouble for shared medium like wireless)
and provided we have onion routing we'd get pretty good traffic hiding.

I'd say there's a clear difference between obfuscation and true hiding.
Ideally we can do true hiding at high efficiency.

My vote is for cutting packages into small bits and onion routing them
around over different paths. Combined with dummy messages and fully random
messages this should more than provide for obfuscation.

Note that very well distributed services, DHT or Bitcoin distributed,
suffer significantly less from all this. You can't really tell which
service(s) one is talking to, only that one is talking to at least one
service. This amounts to an efficient estimation of the continuous
streaming effect.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Lodewijk andré de la porte]

So to be short: no, there cannot.

The absence of new information cannot cause the information needed for
decryption to become known. Unless you find some way to reverse that or use
a hybrid crypto and non-crypto solution a DMS cannot happen.

Anyone disagree?

Note that a Bitcoin-like/distributed network could in potential be an
automated DMS-crypto-cheat.

2012/9/5 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 So , 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 
>> 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=source&output=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 
>>
>> 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
>
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] chaos-based cryptosystem with quantum crypto similarities

[Lodewijk andré de la porte]

I'd like to try and read it, but how do I get it? I have access to two
universities worth of subscriptions so I presume it truly is a matter of
"Where is it?!".

2012/9/29 

>
> I was asked to read this
>
> Fundamentals of a classical chaos-based cryptosystem with some quantum
> cryptography similarities
> Vidal G, Baptista MS & Mancini H
> International Journal of Bifurcation and Chaos
> World Scientific Publishing Company
>
> Abstract: We present the fundamentals of a cryptographic method
>   based on a hyperchaotic system and a protocol which
>   inherits some properties of the quantum cryptography but
>   that can be straightforwardly applied on the existing
>   communication systems of non-optical communication channels,
>   and it is an appropriate tool to provide security on
>   software applications for VoIP, as in Skype, dedicated
>   to voice communication through Internet. This would enable
>   that an information packet be sent through Internet
>   preventing attacks with similar strategies to the employed
>   if this same packet is transferred in an optical channel
>   under a quantum cryptographic scheme. This method relies
>   on fundamental properties that chaotic signals and coupled
>   chaotic systems have. Some of these properties had never
>   been explored to communicate securely.
>
>
> I clearly need to read something else first.
> Suggestions?
>
> --dan
>
> ___
> 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] New mailing list for crypto politics/non-tech (Was: Cypherpunks mailing list)

[Lodewijk andré de la porte]

2013/3/25 James A. Donald 

> You don't have cryptopolitics unless the government is trying to ban
> stuff.  Current bans focus on bitcoins and file sharing.


To politics there is more than the destructive side.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Ripple a.k.a. OpenCoin

[Lodewijk andré de la porte]

2013/6/26 Taral 

>  Truncated sha512 is odd but not wrong, although it seems odd to
> use both sha256 and truncated sha512 in the same application. I'm
> going to assume it's for extensibility in case they decide to go to a
> 512-bit curve.
>

512 is a lot heavier. The truncation makes sense against, for example,
dedicated hardware. The information is spread (supposedly perfectly) over
512 bits, then only 256 bits are publicly known. That makes the possible
input range a lot bigger, lest sha has some special properties making that
untrue.

But it's slightly nicer to use 256 where you can, as it's much cheaper. I'd
say they use "tsha512 where extra security is required"

Maybe any adversary is more likely to go after sha256 FIRST, allowing you
to detect an attack on sha as a whole without exposing your *entire* system.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?

[Lodewijk andré de la porte]

2013/7/19 Mahrud S 

> Isn't the thermal noise a good enough entropy source? I mean, it's a $25
> computer, you can't expect much of it.


"See, sir, you shouldn't wonder why all your data isn't actually encrypted.
You shouldn't think it's weird that nothing is secure on your pc. And that
everyone can fake your digital signature shouldn't surprise you either.
Your computer was only $25. I mean, what'd you expect?"

If it cannot do what it claims, than it shouldn't claim to be able to do
so. We're application layer here, so the OS should put a stop to people
getting bad random numbers. If that means the OS takes 20 seconds to make a
random on a $25 pc, that's okay. It never guaranteed us to be quick. It's
not okay to give us band random numbers. Ever.

A hardware RNG is just another source of entropy I think. But it seems the
Raspberry Pi's RNG should generate random numbers completely on its own.
Without proofs that's a no-no. Not sure that FIPS test is enough proof.

Actually reading the article shows it "LOOKS GOOD FROM HERE" at least. Pff.
You guys get me worked up about nothing.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] evidence for threat modelling -- street-sold hardware has been compromised

[Lodewijk andré de la porte]

2013/7/31 grarpamp 

> And so where does Cisco and Juniper gear come from again... ?
>

Let's not argue about whether Taiwan is China or The People's Republic of
China is China ;)

They do use foxxcon, but it's not clear whatfor. I can imagine they use
foxconn for non-sensitive things. (Like European electronics hahaha).

And they might've moved production in 2000. Or used parts from China.

Regardless of this being rumor mongering, I'm pretty sure the Chinese are
exploiting, backdooring, etc. anything they can.

reg. Australia, of course there's massive amounts of wink-wink going on in
that contract. I hope they give it to a domestic company, like every
government should do. Especially not give it to those contract hungry
Chinese semi-communist central planning extended government
monopolistcorps. Huawei can suck it.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Snowden Induced Mea Culpas

[Lodewijk andré de la porte]

Assume all mayor cryptotools are exploited. Sad but true. Any other reason
people complain OpenSSL is written in tongues (so to speak)? Hiding
exploits is easier in a mess.

That said the people in the IETS might be ignorant to the fact that TLS is
likely backdoor'ed. The thing with this problem is that there's many
layers. Mike Belshe is probably not dual-role, just doing the best he can
is enough.

False security is a danger unlike many others. None of us should forget
that.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] what has the NSA broken?

[Lodewijk andré de la porte]

2013/9/6 ianG 

> Hmmm, curious.  I haven't seen that.  I would also suspect it breaks a lot
> of CPSs and user agreements.  But no matter, they're all broken anyway.
>

A 'user agreement' is an agreement between a company and a 'user'. All
claims in it shall hold valid unless law dictates otherwise. Ask the NSA,
law does dictate otherwise. Note that the NSA is not bound by laws from
countries other than the USoA.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Forward Secrecy Extensions for OpenPGP: Is this still a good proposal?

[Lodewijk andré de la porte]

2013/9/10 David D 

> Quote, " You've got to think (NSA claims to be the biggest employer of
> mathematicians) that seeing the illegal activities the US has been getting
> up to with the fruits of their labour that they may have a mathematician
> retention or motivation problem on their hands."
>
> You mean like the principled mathematicians working on cluster bombs,
> drones, and other "cool shit"?
>
> Everyone at the NSA knows exactly what they are doing.
>
> I suspect, like most that suck off the military-industrial complex tit,
> there is surprising low turnover.
>
> Paychecks only go so far with the principled, but spineless will collect a
> check forever and do whatever it takes to keep it coming.
>

It's just a cool way to work with smart people on difficult problems while
helping the nation.

I think you underestimate how much these Americans think they're genuinely
helping the nation. Their point isn't violating human rights, it's
protecting human beings.

It's a bit like the three laws system in Asimo's books, the only logical
way to protect the civilians against themselves is to prevent them from
thinking and communicating freely. It's only logical to take their freedoms
to make them safe.

I suspect the 'idealistic madmen' actually is a minority. The rest is
simply indifferent to what happens as long as they can do groundbreaking
research.

Analysts are actually "on the job" and the job itself has its ethical
considerations, so that's a different story. Like police really.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Bitcoin-development] REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and others

[Lodewijk andré de la porte]

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.

This is a *big *problem.


2013/9/15 Moritz 

> On 09/15/2013 03:12 AM, Peter Todd wrote:
> > 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.
>
> You have seen the "CoinWitness" proposal?
>
> https://bitcointalk.org/index.php?topic=277389.0
>
> --Mo
> ___
> 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] Dual_EC_DRBG was cooked, but not AES?

[Lodewijk andré de la porte]

2013/9/22 Tony Arcieri 

> Furthermore, 3DES continues to remain a viable cipher.


I, personally, find that a most commendable and remarkable fact. To use DES
with longer keying (and more rounds) is, to this very day, a solid choice.
It makes one wonder why the longer keys weren't used before, doesn't it
make you feel safer that your secret will remain that way until long after
you die?

Performance issues in cryptography are an interesting problem. Both the
safety and inconvenience are in it. It is my preposition that the security
has been minimized too often, and too much.

Longer keys, stronger crypto. This is what I would like to see.

I still think simplicity is something largely ignored in the algorithms.
DES is a *fairly* simple arrangement, AES definitely doesn't improve upon
it. It still seems strange to me that *tricks*, because that's what they
are, require so much trickery.

A simple purpose, a simple solution. You'd imagine.

The simplest algorithm would be the simplest trick to figure out, to undo
the trickery of. Anything more complex would be more difficult to undo, but
will it be more computationally expensive? Are we increasing human effort
or computer effort?

Regarding this topic: typically I'm always disappointed in groups by two
things. The first is the capacity of the group. The second is the kind of
effort being performed to achieve a goal. Usually groups display much
lesser capabilities than individuals do. And the groups will not perform
outside their parameters, meaning they do much less than you'd think they
do to achieve their goals.

I doubt AES is subverted through partaking in the contest. But as those at
the competition I wonder about the abilities of the immense amounts of
cryptographers possibly employed at the NSA. They're careful though. Maybe
we won't ever find out.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] One Time Pad Cryptanalysis

[Lodewijk andré de la porte]

(AFAIK)

Secure OTP depends on two things:

1. Good source. P[i] must be independent to anything in P nor to the method
to generate P. "Random", you'd typically say. Fully unpredictable might be
more clear (given people's unclarity about what's random).
2. No leak of P

Reuse of P leaks P when the plaintext is not as random as P. That leads to
some fantasies towards using crackable cryptographic hashes, that are known
to have very random output. Something like MD5, easily reversible but with
good mixing (afaik). I realize I'm underequipped mathematically to compute
how much you can push that tactic though.

I'm really frustrated with people claiming OTP is insecure. I don't
understand how it is and I cannot seem to construe any angles of attack.
Certainly execution must happen properly, that's no different from anything
else. And that claim is meant as wide as it's written, not as wide as you
just interpreted it. Hell, call it Lewis' natural law. I don't want to
describe how negatively I think about people claiming OTP doesn't work,
this list is negative enough.

2013/9/28 John Young 

> This is simply treasonous. Security clearance voided.
> You be squished soon by boot stomper for 1%.


I must say that for a scientist you're not one to be exact in your use of
language.


> At 07:40 AM 9/28/2013, iang wrote:
>
> They should be given something that won't screw up.  Which means it needs
> to be simple enough such that all the decisions are already made.
>
> In my work, I've evolved into an OO pattern which I call a Cryptor.  It
> has everything built in:  creation, storage, encrypt, decrypt as required.
>  Plus heavy ouroboris testing.
>
> The idea is modular, eg PK Cryptor is built out of an AES/CBC Cryptor and
> a HMAC Cryptor, etc.
>
> Another example is the API provided to do curve25519xsalsa20poly1305
> (which is in C so not OO).
>

How does this differ from using a library to do the crypto?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] One Time Pad Cryptanalysis

[Lodewijk andré de la porte]

2013/9/30 Florian Weimer 

> 3. Message integrity does not matter.
> 4. The security proof assumes there is only one message, ever.


3 and your paper about VOIP regard traffic analysis. I'm not sure what else
3 refers to. Certainly a known plaintext attack would negate that part of
the message, but then it wasn't very encrypted in the first place, was it?
Then you can of course replace part of the message, and if you have a
partial plaintext you might even make it not-garbled, but then still I
think you should apply mixing/scrambling before OTP'ing your plaintext.
There's quite a selection of ways to do that.

I agree this is relevant in some applications. In others it can be fixed.
For example by mixing by doing AES (or something better) with the first x
bits of the OTP. Just to mix, not to encrypt. But then a (mayor) flaw in
AES could provide the opponent with a partial plaintext attack against AES
an attack on whatever touched that data in the OTP'ed output. Hmm. Even a
simple mixer exclusively using the beginning of the pad for secret
information must be able to simply mix the input. AES should be able to do
that much, I doubt it would so broken it wouldn't do that.

And of course I don't think we can consider traffic analysis a breach of
encryption. Not that I think it's not breach. But it's not related to OTP.
You could apply traffic analysis even on plaintext. Point is that it's a
breach of security from another piece of the system (the whole) than the
one we are discussing.

4 regards the notion that a One-Time-Pad is only used One-Time. I agree,
but reuse of any form will either make P leak or it will not be a problem.
There's no real reason to use P multiple times and it is very hard to be
sure you are not leaking information about P when you reuse. I judge this
4th requirement to be redundant to requirement 2. Although it is still
correct, of course.

I might've misunderstood the meaning of these points. I'd like to have
misunderstood, then there is something to learn.

P.S.: Why is that paper 15 pages long? I mean, really. It's just
correlating input letter (in voice), where possible, with the output
bandwidth and it's changes. Of course there's hundreds of little annoying
things from several disciplines. I guess they did it thoroughly, then the
paper should be thorough. Fine.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] How big a speedup through storage?

[Lodewijk andré de la porte]

With common algorithms, how much would a LOT of storage help? I know this
one organization that seems to be building an omnious observation storage
facility, even though omnious observation has very mixed effectiveness
(read: not really worth it), and I'm wondering; is the NSA planning on
using it to assist breaking the vital data?

I'm not sure distributed processing and huge datastorage has been as fully
evaluated as computational finding has been.

It's conspiracy thinking, of course, but it seems so strange to me that
they let us know what they're building the facility for. Maybe it's
something stranger? Something they needed a huge cover for? Something they
could cover given circumstances?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How big a speedup through storage?

[Lodewijk andré de la porte]

2014-06-20 21:46 GMT+02:00 Greg Zaverucha :

> Hi Lodewijk
> Here are some relevant references.
>

Thanks!


> A cryptanalytic time-memory trade-off.
> ME Hellman - IEEE Transactions on  Information Theory, , 1980
> http://www.cs.miami.edu/home/burt/learning/Csc609.122/doc/36.pdf
>

This is pretty basic. It's become common knowledge, apparently a valueable
paper then :). This one is a little more archaic than my current timespan
allows me to process properly.

It's also important to remember that whatever tricks will be used they are
most likely not public knowledge.


> Making a Faster Cryptanalytic Time-Memory Trade-Off.
> P. Oechslin.  CRYPTO 2003
> http://lasec.epfl.ch/pub/lasec/doc/Oech03.pdf
>

Ah yes, rainbow tables :) I remember making one for MD5 in school with PHP
and MySQL. Worked decently, but not enough storage/preprocessing time to
really get further than those available for free online. Good fun though.
PHP is very easy to just use. I think mine wasn't as good as it could've
been if I'd had proper references. No way to dig it up though.

Some funny stuff here too; "They present a detailed analysis which is
backed up by simulation in a purpose-built FPGA.". What is a purpose-built
FPGA? FPGA's are adaptable, that's the whole point! If it were purpose
built it'd be an ASIC, and not an FPGA at all. Nice paper, but already more
or less "common knowledge".


> Understanding brute force.
> Daniel J. Bernstein
> http://cr.yp.to/snuffle/bruteforce-20050425.pdf
>

First line hits home "There is a widespread myth that parallelizing a
computation cannot improve its price-performance ratio.". The term
price-performance is accurate, but price no longer means what it should for
the scale of the agency concerned. It's more about humanly possible, I
think.

It's interesting that the whole paper comes no futher than showing that the
myth does not hold true. That's good, but it does not go as far as it could
at all.

It also has a more general comment;" “*But 256-bit AES deliberately uses 14
rounds to keep us secure against non-brute-force attacks!” some people will
argue. “There’s an 8-round attack taking time only 2 204 , for example.
Okay, okay, that’s on a machine with 2 104 bits of memory, but maybe some
additional ideas will produce a 10-round attack more efficient than a
256-bit parallel brute-force key-search attack.” *". It is my understanding
that the rounds are required for diffusing the input. Using less rounds
than a certain threshold fails to achieve sufficient blending of the input,
and creates strong patterns in the output. In other words: it completely
breaks diffusion. Therefore the detriment to the security factor of AES is
much stronger than is suggested in this alinea, as patterns arise where
there previously weren't.


The type of attack that I see the most profit in would be one that adopts a
variant of a "meet in the middle" attack. It moves away futher from the
centralized point of execution. We have a function family generator F(key,
step) that can create a function to be performed on a cyphertext C(step),
where key is a random-walk-value used in the attempted decryption and the
step is a "class". The function will only execute on programs with the
right class. F's results are compared to succesfully completed decryptions,
possibly seeded with foreknowledge.

F is supposed to generate/consist of functions that find patterns or
perform mutations. In a serial machine this would be completely unfeasible,
not unlike Neural Network simulation is uninteresting. But in this parallel
machine "transient" paths will be untangled by converging on a nearby
physical location. IOW: the result of a function generated by F determines
the next function to be executed, and the functions are mapped out over the
machine. The machine will thus automatically bring similar results closer
together which allows for deduplication. If one is able to deduplicate with
a known-decypherment then a more serial/central process is supposed to take
note of that, and test a key coming forth from that or at least shift the
probability of working with a certain class of keys (that share a property
extracted by the functions).

This is a meet in the middle attack because in the end there will have to
be brute forcing, but the intermediate results are an optimization of it.
Additionally there will be many "middle points" floating around the machine
at any given point in time.

This is not the whole story however. The really interesting trick is that
many different cyphertexts will propagate through the machine at the same
time. Not only are middlepoints matched within a certain cyphertext, but
also across multiple cyphertexts. This could be especially interesting when
the key is (partially) shared.

The really hard thing is the construction of F. F will have to generate
functions with an understanding of how patterns should arise given certain
steps, and how they shouldn't. There's an advantage to integrating common
plaint

[cryptography] Finally! Hyperledger is a "trust N out of a selected M" ledger system!

[Lodewijk andré de la porte]

http://hyperledger.com/

With this nifty little tool one can manage pools that validate
transactions. So instead of a consortium of anonymous miners motivated
exclusively by profit you can trust a consortium selected according to a
predefined procedure.

Then if you trust the procedure, you can probably trust the consortium.
With the trust problem solved you are very likely to be able to happily use
money as you should.

Fizz-bang Bitcoin is much less unique and useful. People will have a
cheaper alternative that seems like it's just as good and more usable.

Problem is that consortia are never good enough. There's always too big an
opponent that can take down too much of a consortium. Bitcoin is a tease
stronger than that. But much more expensive.

I don't think it will take off though, there doesn't seem to be an early
adopter advantage.

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

[cryptography] Browser JS (client side) crypto FUD

[Lodewijk andré de la porte]

http://matasano.com/articles/javascript-cryptography/

Is surprisingly often passed around as if it is the end-all to the idea of
client side JS crypto.

TL;DR: It's a fantastic load of horse crap, mixed in with some extremely
generalized cryptography issues that most people never thought about before
that do not harm JS crypto at all.

I'm not sure why the guy wrote it. Maybe he's NSA motivated? Maybe he's
worked a lot on secure systems and this just gives him the creeps? Maybe
he's the kind of guy that thinks JS dynamic scripted languages
are not a real languages?

Somebody, please, give me something to say against people that claim JS
client side crypto can just never work!

-
Aside from that it's, well, fundamentally moronic to claim that something
is "harmful" when you actually means it does nothing, it's also just
(almost!) never true that no attacks are prevented.

But, let's go with the flow of the article. Rants won't really settle
arguments.

Two example usages are given.

The first is client-side hashing of a password, so that it's never sent in
the clear. This is so legitimate it nearly makes me drop my hat, but, the
author decides to use HMAC-SHA1 instead of SHA2 for reasons that are fully
beyond me. Perhaps just trying to make things less secure?

The second is using AES keys to client side encrypt. The author must've
thought he was being helpful when he imagined the scheme for this. Or maybe
he was drunk. "So you generate an AES key for each note, send it to the
user's browser to store locally, forget the key, and let the user wrap and
unwrap their data.". Somehow trusting the transport layer is all back in
vogue. The only key-generation problem in JS is entropy, which is a problem
everywhere tbh. If you really want to ensure entropy, send a random data
blob and XOR it with whatever client-side best-shot at randomness.
Whatever.

The author bluntheadedly claims "They will both fail to secure users". In
principle I agree, his methods sucked balls. He, however, blames it on JS.
Okay.. Let's go on.

REALLY? WHY?
> For several reasons, including the following:
> 1 Secure delivery of Javascript to browsers is a chicken-egg problem.
> 2 Browser Javascript is hostile to cryptography.
> 3 The "view-source" transparency of Javascript is illusory.

Until those problems are fixed, Javascript isn't a serious crypto research
> environment, and suffers for it.

(points numbered for pointwise addressing)

1 - Yeah. Duh. What do you think of delivering anything client side?
There's the whole SSL infrastructure, if that doesn't cut it for you, well,
welcome to the Internet. (I suggest the next article is about how the
Internet is fundamentally flawed.) I would suggest, however, that once your
delivery pathway is exploited you're fundamentally screwed in every way.
You can't communicate anything, you can't authenticate anyone, you really
can't *do* anything! So let's leave out the "Javascript" part of this
point, and just do whatever we're already doing to alleviate this issue.

2 - This is a conclusion without any basis so far (aside from being..
meaningless to a computer scientist. Hostile?)

3 - Then just look at what data was transferred. Does every crypto
application require checkable source? Is any SSL implementation "considered
harmful" because nobody is able to flawlessly read the code, no compilers
are trusted, etc?

Okay so that chapter meant absolutely nothing. The author goes on to try to
defend his brabble:

"WHAT'S THE "CHICKEN-EGG PROBLEM" WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY?

If you don't trust the network to deliver a password, or, worse, don't
trust the server not to keep user secrets, you can't trust them to deliver
security code. The same attacker who was sniffing passwords or reading
diaries before you introduce crypto is simply hijacking crypto code after
you do."

A fair point against a single thread model. Interestingly the last line
does absolutely not have to hold, sniffing (after the fact) and on-the-fly
rewriting are worlds apart. Take Tempest of Xkeyscore, for example, they
can't do rewrites. They need specialized programs for that. (Conclusion:
nope, nothing to see here)

The next chapter tries to justify the fallacies made earlier on. Equating a
rewrite to a read, ad-homineming the JS crypto "industry" (and failing to
distinguish operational security from actual security), and lastly claiming
that misplaced trust is bad (which is obvious and unrelated).

The next chapter claims SSL is safe, and "real" crypto unlike JS crypto.
Then firmly cements his baseless ridicule by claiming that if you use
non-JS crypto to make JS crypto work, then obviously there's no point.

The next chapter "WHAT'S HARD ABOUT DEPLOYING JAVASCRIPT CRYPTO CODE OVER
SSL/TLS?" claims all the page has to be SSL/TLS and that makes it hard.
It's not hard and you should already be doing it to have /*any*/ security.
Not to mention it's not true, only tha

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

[Lodewijk andré de la porte]

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).

Best regards,
Lewis

* It'd probably siphon down from a Linux OS, but ofc the code is portable
so randomness is probably low quality too.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Finally! Hyperledger is a "trust N out of a selected M" ledger system!

[Lodewijk andré de la porte]

2014-07-11 12:38 GMT+02:00 L. M. Goodman :

> B)
>
> As I've mentioned before, I think the gap can be bridged by using social
> networks to form consensus... but it's tricky. I've been playing with some
> datasets from G+ and Facebook (snap.standford.edu) but they were too
> incomplete to be useful
>

Any such method tolerates inconsistencies. One end of the graph can have a
different financial reality than the other. That's fine as long as it
somehow still works out, usually. It probably won't, not with money.

It can work out with money through something zeroreserve
like.
___
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?

[Lodewijk andré de la porte]

Thanks for the responses everyone!

Reg. making a CSPRNG in JS: I don't have experience and wouldn't trust it.
Using someone else's is even worse, I find other's often do things even
worse (somehow). And seeding it would sort of have moved the problem rather
than solving it. A PRNG shouldn't be able to generate entropy out of
nothing and I don't really feel like doing the cryptanalysis (or trusting
someone else's ;) (but it's probably a decent way to do it, I've seen a JS
Fortuna for example)

Everyone else told me basically the same thing, but somehow it all made
complete sense only after James' comment.

It sounds like what you want is a way to generate randomness a user
> can trust, in a browser lacking crypto.getRandomValues.  That's hard
> to impossible - it's why crypto.getRandomValues was made.  I believe
> state of the art prior to crypto.gRV was using mouse movements and
> other server-unpredictable events.


That's exactly it! I'm not 100% on the security of the wiggle-mouse based
entropy, still seems a bit too sketchy to me. I'd also prefer not to annoy
users any more than I have to. It's also just a lot of hassle. Do
touchscreens provide the same entropy? What about a user with a *very* slow
phone (maybe an update in the background)? Prefer avoiding dragons, even if
they seem small enough to slay.

If I just hand the user data it's deferred computing, not clientside
crypto. There's also the question of whether crypto.getRandomValues can be
trusted. Where does the browser get it's entropy? Does the browser add
flaws? HTML runs on a wide device landscape, PC's, Game Consoles,
SmartTV's, e-readers, smartphones, etc. (in the future they'll support the
current HTML5 or I may support them, now I doubt many would run my website
properly)

As an added bonus I can more easily reach users that just don't care. If
you get a stern warning to upgrade or suffer decreased security and ignore
it, I'd like to say I don't have to care. The problem is that users are
unknowing, so you can't expect them to respond to such a warning. Now I can
rest easy knowing I gave them good randomness. The client-side randomness
assurance couldn't be important to people running aged software.

So, thanks everyone, for checking my sanity. Wouldn't know what to do
without a list like this.
___
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?

[Lodewijk andré de la porte]

Come to think of it, is there or why isn't there a block-cipher mode that
chains using a hashing algorithm?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Possible SigInt Metadata Dump Files Circulating

[Lodewijk andré de la porte]

Just to check if I'm getting this correctly: There's an immense amount of
sigint data that's (being) leaked into public infrastructure - and
wilf...@vt.edu is telling us about it?


Can we access this data **? How is Wilfred knowing of this, and allowed to
speak of it? Why not speak of the onloader's identity?

Tracking cash currency is certainly interesting from many standpoints...
actually doing it seems outrageous. Leaking this data intentionally is
extremely outrageous - no matter the target's value the laundering can not
warrant the backlash. As a politically minded shake-up-leak, this one is
the most daring so far, and would most likely be the most effective at
dismantling the espionage engine. It almost seems too good (and in a way
terrifying*) to be true...

Is dear Wilfred pulling our legs? How would we know at this point?

Assuming truth.. please validate known NSA locations and other US-secret
areas. If the dataset is manipulated at all - and one would assume that it
is - it should exclude sensitive persons first. Sensitive persons should
hang out near sensitive person areas - if the sensitive person area's are
less full than they should be Think Obama sitting in the white house
and going home, think the first family, think area 51, think coins not
being attached to people properly. Note that notable persons may be
falsified, so ideally one would find an atypically understaffed military
base or something of the like. Perhaps an agent/secret-base that was
exposed? All those that entered an Internet-tap-room in a datacenter?
Military ships' crewmen? If such data-gaps are found/indicated, compare it
to other nations and you'll know which who's data you're receiving
(although everyone understands it'd probably be the USGOV/NSA).

Wilfred, are you publishing this to prevent the data just disappearing?

* I'd actually really like to know where I've been in the past, and I
know *they
*know but won't tell me. And the amount of exceedingly valuable scientific
(census) data one could parse from such a database Still, we'd move
rather suddently from panopticon to omniopticon (a term I thought of to
describe "everyone watches everything" instead of "they watch everything".
I know it's not a flawless name but it works).

** I realize there's no way we're going to store or transfer this much data
- but there should be something that can be done to preserve this dataset!
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Possible SigInt Metadata Dump Files Circulating

[Lodewijk andré de la porte]

It's been 4 days with no evidence. Last e-mail of Wilfred's e-mails seems
downright erratic. Hope this at least goes *somewhere*. Probably not,
though.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] a little help with cookies please

[Lodewijk andré de la porte]

No. Every request has a header with the cookies in it.

Again: /every request contains the cookie/

This is also a reason for placing static content on a seperate server; it
saves bandwidth by not sending the cookie in the request.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Lodewijk andré de la porte]

>
> I'd agree that "forums" are a poor choice.
> They're magnets for masses of the clueless,
> which is fine for that purpose.


They are easy to use, rather than archaic and unappealing. Not sure what
kind of argument this is, anyway.


> And they're heavyweight, captive, and exploitable.
>

My computer is also heavyweight, so they're equally responsive.

They are typically captive by design, to allow commercial exploitation of
the attached community. You'll note the user agreement typically causes
every submission to be property of the forum's owner. These issues are just
not related to the format proper.

I do not see how it is more or less exploitable than e-mail. Certainly, the
interface is richer, and more is possible for both good and evil. That all
just depends.


> Lists can be archived, replicated, distributed,
> offlined, searched with any MUA, etc. +1.


Why would a MUA search a forum? Why is a forum less archivable, replicable,
or distributable/p2pifieable?


If anything this shows how much you have been remiss, not developing a
modern mode of interaction that complies with your demands. To stay with
Fax is certainly functional, and it will readily appeal to those accustomed
to that format, but to actively defend the superiority of the dated is
foolish.

You're probably right though. Current forum software is an ongoing
disappointment, where e-mail steps into a rich tradition of letter-writing.
I'd say e-mail lists suffer primarily indigestibility through lack of
overview, a lack of multimedia, a lack of interlinking, a lack of hope for
"better than just threading". Ultimately most time is spent parsing text -
so cutting away everything around it (as you seem to have done) is a great
way to optimise if you read everything anyway.


> pardon the dispersion, my question / objection is about the way ZCash
> responds to people that have lost money in financial gambling due to
> the hyped ICO price at ZCash entrance. So far I understand your
> response has been to treat a lawsuit for people using your (tm'ed)
> logo for instance with the @ZCashVictims account on Twitter.


So, there's this thing with risky investments... Hmm. Oh, I recall: you
carry your own risk.

ZCash*Victims*? Certainly, everyone that participated is him/herself a
perpetrator. Every investment an endorsement of this heightened value. One
thing to cry about spilled milk, another to call yourself @milkspillVictims.

note: an ICO has no promise of future value, participating on a market like
Coinbase and getting your stop-losses ran is almost an edge case (Coinbase
allowed overlarge capital influx, causing one of their features to behave
outside normative expectations) but still really your own fault (part of
the game with the rules as they are). I'd say exchanges going bankrupt for
mismanagement - that's a little over the line between "upset" and
"retribution".

that's arguable on more levels, yet from what I understand you don't
> have further control: you have adopted what seems a rather smart
> mining incentive curve on the first 34 days. This certainly does not
> means you have control on the market price, but you have well planned
> mining incentives (and market price is a collateral of it) and this
> plan is public.


As you said, this plan is public. Forks could do away with unfair
incentives, but don't.

this is a good answer, in particular your declaration that you
> "haven't bought or sold any ZEC". I believe you should give this
> answer to those people considering themselves victims of a market
> gambling operation you do not take part into.


Victims to gambling? Do you hear yourself speak?

If we're victims of anything it's the lies of capital - those ideals
enshrined within property that do not support our natures, nor our
realities. We have a collective maths engine, it makes it apparently
impossible to do certain maths without certain information, and bam, you
become a victim! A VICTIM! You /lose some part of yourself/ because you
actually identify with your property! They promised you riches beyond
reason, and all you got was what you bought!
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[lodewijk andré de la porte]

> On 7 Jul 2017, at 22:52, Jaromil  wrote:
> 
> On Tue, 04 Jul 2017, Lodewijk andré de la porte wrote:
> 
>> this is a good answer, in particular your declaration that you
>> "haven't bought or sold any ZEC". I believe you should give this
>> answer to those people considering themselves victims of a market
>> gambling operation you do not take part into.
>> 
>>   Victims to gambling? Do you hear yourself speak?
> 
> I have *written* it reporting the interpretation of circumstances by
> these people who are calling themselves victims of ZCash in public and
> then satisfied by the answer given by ZCash representatives here.
> 
> The reason why I'm debating this is that I find it very interesting
> what is happening around ICOs, both as a researcher and as a crypto
> investor.
> 
> What is the need to bring this debate to an ad-personam attack, if not
> the increase in testosterone production due to the current heat wave
> in .nl? but then please, do us a favor...
> 
> ciao

I don’t like your tone either, doesn’t mean I ignore your statements.

Is this some sort of high road in your worldview?

Is it witty to take an obvious figure of speech literally?

What satisfaction did you obtain?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography