[Cryptography] cryptography Digest, Vol 56, Issue 22
Francisco Hernández Parga
f.hernandez.parga at gmail.com
Fri Dec 22 14:29:25 EST 2017
I think this is an interesting article about the history of cypherpunks and how bitcoin and cryptos were born. Worth the read and I hope people stop killing great projects with stupid finance... https://medium.com/@franparga/this-time-is-different-9a5feeb6975b
Thank you for keeping this mailing list alive!
Enviado desde mi iPhone
> El 22 dic 2017, a las 18:00, cryptography-request at metzdowd.com escribió:
>
> Send cryptography mailing list submissions to
> cryptography at metzdowd.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.metzdowd.com/mailman/listinfo/cryptography
> or, via email, send a message with subject or body 'help' to
> cryptography-request at metzdowd.com
>
> You can reach the person managing the list at
> cryptography-owner at metzdowd.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cryptography digest..."
>
>
> Today's Topics:
>
> 1. Re: paragraph with expected frequencies (John Denker)
> 2. Re: Rubber-hose resistance? (Patrick Chkoreff)
> 3. Re: Lakestone Bank and Trust Just Made A Problem, Oopsie
> (Georgi Guninski)
> 4. Bitcoin, fork you very much (John Levine)
> 5. Re: Rubber-hose resistance? (Nico Williams)
> 6. Web voting service (Phillip Hallam-Baker)
> 7. Re: Rubber-hose resistance? (Jeremy Stanley)
> 8. Re: Bitcoin, fork you very much (Natanael)
> 9. Re: Bitcoin theft and the future of cryptocurrencies
> (Tom Mitchell)
> 10. Zcash 2nd Ceremony Call for Review / Participation, @Snowden
> EFF ACLU Privacy Updates (grarpamp)
> 11. Re: Rubber-hose resistance? (Jerry Leichter)
> 12. Re: Rubber-hose resistance? (Peter Gutmann)
> 13. Re: Rubber-hose resistance? (Jeremy Stanley)
> 14. Re: paragraph with expected frequencies (Robin Wood)
> 15. Re: Lakestone Bank and Trust Just Made A Problem, Oopsie
> (John Levine)
> 16. Re: Rubber-hose resistance? (Patrick Chkoreff)
> 17. Happy birthday, Tommy Flowers! (Dave Horsfall)
> 18. Cybersecurity Regulation for Crypto Exchanges (Aimable Niyikiza)
> 19. Re: Rubber-hose resistance? (Gé Weijers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Dec 2017 07:07:41 -0700
> From: John Denker <jsd at av8n.com>
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] paragraph with expected frequencies
> Message-ID: <e0be2c4b-6084-c4b3-c0b7-a73b25af93d0 at av8n.com>
> Content-Type: text/plain; charset=utf-8
>
>> On 12/20/2017 02:02 AM, Robin Wood wrote:
>> I'm working on a bit of crypto with my young daughter and we are about to
>> look at frequency analysis. Are there any short UK English paragraphs where
>> the frequency of letters is about what you would expect based on frequency
>> charts? i.e. E then T, A and O.
>>
>> Bonus if the digraphs are also roughly in order.
>>
>> I want to count the letters by hand so don't want anything too long and it
>> has to be PG content.
>
>
> The question is both trivial to answer, and impossible.
>
> It is trivial for linguistic and cryptological reasons:
> Almost any reasonably large sample of English will
> display characteristic English letter-frequencies.
>
> This is not mathematically guaranteed; it is just a
> known property of natural language.
>
> It is an important property. Frequency analysis is
> not a known-text or chosen-text attack, where you
> know a_priori that the text has the exact "expected
> frequencies". It works for any halfway-reasonable
> text. This is the fatal weakness of any monoalphabetic
> substitution cipher.
>
> ==========
>
> In contrast, there are good mathematical reasons why
> no finite sample will display the "expected frequencies"
> exactly.
>
> Frequency is a type of probability. There are lots of
> probabilities in this world, and lots of frequencies.
> In this case we are particularly interested in the
> /population/ i.e. all possible texts, which is an
> effectively infinite set, and various finite /samples/
> that might be drawn from the population. Statisticians
> give these terms technical meanings which unfortunately
> diverge from the meanings in any other context, but
> let's stick with the statistical definitions here.
>
> The frequencies observed on any sample will converge
> to the frequencies on the population in the limit
> of large sample-sizes ... but we are talking about
> convergence in the limit, not equality for any finite
> sample.
>
> For any finite sample, /statistical fluctuations/
> guarantee that the sample frequencies are expected
> to differ from the population frequencies. You can
> use properties of the population to predict the
> distribution of fluctuations (as a function of
> sample size) if you want.
>
> The larger the number of observables (e.g. the 26
> different letter frequencies) the smaller your
> chance of seeing the "expected frequencies" exactly.
>
> On the other hand, the point of the exercise is
> statistical /inference/. Frequency analysis allows
> you to infer that the text is English, as opposed
> to gibberish. With a reasonable-sized sample, you
> can infer this with high confidence _despite_ the
> fluctuations. The confidence will never be exactly
> 100%, because the tail of the English distribution
> will overlap the tail of the gibberish distribution
> "somewhat", but this is not a problem in practice.
>
> Even if you could hunt up a sample that did have
> the exact "expected frequencies", it would be very
> unwise to use it as the basis of a lesson, because
> it would teach a wrong lesson about statistical
> fluctuations and statistical inference.
>
> ==> A much better lesson would be to repeat the
> experiment with a few different sample-sizes from
> the same source, to demonstrate the mathematical
> point about fluctuations and convergence ... and
> then compare a few disparate sources (e.g. Dickens
> versus Rowling), to demonstrate the linguistic
> point about near-invariance of the frequencies.
> Thirdly, histogram a random process (diceware)
> as a control.
>
> Counting using tally-marks (a) is easier and (b)
> constructs a histogram on the fly. Plot a large
> sample with N subsamples, using N colors of ink,
> all on the same cumulative histogram, so you can
> see the fluctuations and the convergence at a glance.
>
> Digraphs converge 26 times more slowly, for obvious
> reasons, and so require much larger samples. This
> should come several turns later on the pedagogical
> spiral.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Dec 2017 09:09:42 -0500
> From: Patrick Chkoreff <patrick at rayservers.net>
> Cc: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <79f6cef6-bdf9-e5ee-8c19-40ffc5e6ee9b at rayservers.net>
> Content-Type: text/plain; charset=utf-8
>
> Jerry Leichter wrote on 12/20/2017 10:29 PM:
>
>> Then you don't understand how SSD's work.
>>
>> The number of pages actually available inside the SSD may be - likely is - quite a bit larger than the size visible outside the device. When you write a block, it goes on some page. You don't know - there's no interface to find out - what page that block lies on. If you write the same block again, it almost certainly ends up on some other page. The old page goes into a "to be erased and reused later" list.
>
> Thanks, that's good to know.
>
>
>> Just because you filled up every block does not mean the list of free pages is empty. Nor does it mean those pages have been erased.
>>
>> There is simply no way to know you've erased all the pages in an SSD using only the interface the device presents to you that makes it look like a disk.
>
> Got it.
>
>
>> If you don't know enough about how the device you are trying to erase is organized internally to rule out or rule in such possibilities, you have no business claiming you have an effective erasure tool.
>
> Now I claim the opposite: No such tool exists, and it is impossible to
> create one in software only.
>
> The border crossing scenario just got more difficult. If you copy
> anything to the laptop, and then try to erase it using software
> techniques only, there is no way to be sure that it's gone.
>
> I suppose now it's safest just to shred the SSD physically before you
> return from the trip. Either return with no hard drive or install a spare.
>
>
> -- Patrick
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Dec 2017 17:07:28 +0200
> From: Georgi Guninski <guninski at guninski.com>
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Lakestone Bank and Trust Just Made A
> Problem, Oopsie
> Message-ID: <20171221150728.GC844 at sivokote.iziade.m$>
> Content-Type: text/plain; charset=us-ascii
>
>> On Wed, Dec 20, 2017 at 10:33:20PM -0500, grarpamp wrote:
>> OP's:
>> https://www.facebook.com/groups/Ethereum/permalink/1393594610766582/
>> 294 Likes843 Comments189 Shares
>> https://www.facebook.com/LakestoneBank/
>> https://m.facebook.com/LakestoneBank/reviews/
>> https://www.reddit.com/r/Bitcoin/comments/7l461c/banks_trying_to_come_down_on_crypto_investers/
>>
>
> This greedy bank well might kill herself, possibly downing large
> amount of the rest of Ponzi scheme banks.
> It is enough critical (possibly not large) part of their lusers
> to ask their money back.
>
> This leads to the question:
>
> How would a cryptocurrency work if the banking system is down or there
> is global hyperinflation?
>
> AFAIK the bitcoin core blockchain is about 150G and it can't track
> every beer bought for pico BTC.
>
>
>
> ------------------------------
>
> Message: 4
> Date: 21 Dec 2017 11:20:42 -0500
> From: "John Levine" <johnl at iecc.com>
> To: cryptography at metzdowd.com
> Subject: [Cryptography] Bitcoin, fork you very much
> Message-ID: <20171221162042.4D3B1183C4A3 at ary.qy>
> Content-Type: text/plain; charset=utf-8
>
> Let's say I'm with the Chinese government and decide that I am tired
> of people evading currency controls and money laundering with Bitcoin.
> So we adjust the Great Firewall of China to block port 8333. We also
> add some MITM proxies that take newly mined blocks from the Chinese
> side, rewrite them to put the newly mined btc into government-approved
> wallets, fill up the blocks with transactions from outside China, and
> send them along.
>
> Since a large fraction of the miners are inside China and all of the
> hard currency exchanges are outside, this is a pretty serious fork.
> No doubt people will start trying to evade the block, but the the GFoC
> works pretty well, and any evasion will take a while to start being
> effective. It'd also be easy to tell who was trying to evade (look at
> the blocks in the chains they publish) and send someone around to chat
> with them.
>
> Even if the two sides are eventually reunited, then what? It'd be
> obvious which blocks had been rewritten, but even if there was some
> improbable global consensus to disregard them, what happens to all of
> the transactions?
>
> Am I missing anything important here?
>
> R's,
> John
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 Dec 2017 10:37:16 -0600
> From: Nico Williams <nico at cryptonector.com>
> To: Jeremy Stanley <fungi at yuggoth.org>
> Cc: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <20171221163714.GA12282 at localhost>
> Content-Type: text/plain; charset=us-ascii
>
>> On Wed, Dec 20, 2017 at 06:31:24PM +0000, Jeremy Stanley wrote:
>> Also, when crossing some borders, your devices may leave your person
>> and be out of visual range for extended periods of time before you
>> get them back. In such circumstances do you consider them probably
>> compromised (perhaps even at the firmware or hardware level) and
>> quarantine or dispose of them accordingly?
>
> If that happens you just dispose of the devices.
>
> A simple defense against this sort of attack is to carry just a
> raspberry pi and an SD card with a minimal OS and content. You can
> always buy a new SD card, download an image, and build yourself a remote
> access terminal. It's pretty simple. It's not likely that customs will
> have a hardware attach for every SBC out there, and you can always
> inspect it, as these computers are very small and their boards highly
> accessible.
>
> If you stay at a hotel then chances are you can just display onto the
> room's TV with an HDMI cable. Or you can carry a 14" portable display
> -- these are widely available and cheap.
>
> You will have to carry a keyboard and mouse, but that's a plus. I
> always do anyways for ergonomics reasons, and maybe so should you.
>
> This approach compares well to a proper laptop if all you'll be needing
> is a terminal anyways.
>
> Nico
> --
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 Dec 2017 13:09:45 -0500
> From: Phillip Hallam-Baker <phill at hallambaker.com>
> To: Cryptography Mailing List <cryptography at metzdowd.com>
> Subject: [Cryptography] Web voting service
> Message-ID:
> <CAMm+LwjdVTfoY_4bdjh6tk+OGnsa7B8nQB3u0fZcfhD_Wmi4TA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I am currently deploying the Mesh services for an external test and looking
> for small, self-contained applications that can be supported thereon.
>
> The basic premise of the Mesh is that it becomes really easy to do a lot of
> cool cryptography iff we get to a point where use of private keys for
> security purposes is as fluent as passwords.
>
> One facility I will eventually need is the ability to checkpoint assertions
> about public keys in a linked hash log (aka Blockchain). Since I am not of
> the proof of work faith, I am looking to DAG type approaches to assure
> integrity of the hash log (aka HashGraph). So I am looking for a smallish
> project that could showcase the effort and create a nucleus of services
> that could later be built into a HashGraph infrastructure.
>
>
> One facility I think we need is the ability to record non-anonymous votes.
> This happens a lot in industry consortia where each member has a vote and
> the way that they vote is public. [Yes anonymous is more interesting as a
> problem but that can be built on the public voting scheme].
>
> So the basic idea is that there is a Web Service that accepts two types of
> data and records them in a hash log:
>
> 1) Votes
> 2) Witness values.
>
> Assume I am not stupid and the votes are authenticated appropriately,
> timestamped, etc. Votes can be encrypted until the close of the ballot is
> declared, etc.
>
> The Witness values are any unpredictable value published by any other
> source that can be verified retrospectively. For example:
>
> * A signed time source
> * Any block chain output
>
> Each witness value contains sufficient information to allow a third party
> to verify it. Typically this would be a URI and possibly a date-time or
> index value.
>
> The hash log is signed every n minutes. When a vote (or any other value) is
> enrolled in the hash log, the service provides a signed receipt. This
> enables the voter to call fraud should their vote not be recorded. [For
> additional bonus points we can add in Micali Fair Contracts which went out
> of patent recently]
>
>
> Now consider a situation in which there are multiple vote servers accepting
> votes on the same ballot. If one goes down, another server can accept it.
> All the vote counter then needs to do is check all the approved logs. This
> prevents a form of fraud where the vote server goes down (or is DDoSed)
> when the ballot is in one side's favor.
>
>
> One building block for such a system would be a disclosure service which
> publishes a list of public keys and then releases the corresponding private
> key at a specified time. So I would probably publish key pairs for each
> hour for the next 30 days, for each day for the next year and each week for
> the next decade on a rolling basis. Easy enough to do from a single master
> secret.
>
> Using the same techniques as proxy re-encryption, people can choose
> multiple services and build n of m type quorum schemes using Shamir secret
> sharing on top. So if encrypted ballots are used and one of the disclosure
> services dies, the system remains robust.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/fc6905aa/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 Dec 2017 18:53:50 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <20171221185350.GZ13067 at yuggoth.org>
> Content-Type: text/plain; charset="utf-8"
>
>> On 2017-12-21 10:37:16 -0600 (-0600), Nico Williams wrote:
>>> On Wed, Dec 20, 2017 at 06:31:24PM +0000, Jeremy Stanley wrote:
>>> Also, when crossing some borders, your devices may leave your person
>>> and be out of visual range for extended periods of time before you
>>> get them back. In such circumstances do you consider them probably
>>> compromised (perhaps even at the firmware or hardware level) and
>>> quarantine or dispose of them accordingly?
>>
>> If that happens you just dispose of the devices.
>>
>> A simple defense against this sort of attack is to carry just a
>> raspberry pi and an SD card with a minimal OS and content. You can
>> always buy a new SD card, download an image, and build yourself a remote
>> access terminal. It's pretty simple. It's not likely that customs will
>> have a hardware attach for every SBC out there, and you can always
>> inspect it, as these computers are very small and their boards highly
>> accessible.
>>
>> If you stay at a hotel then chances are you can just display onto the
>> room's TV with an HDMI cable. Or you can carry a 14" portable display
>> -- these are widely available and cheap.
>>
>> You will have to carry a keyboard and mouse, but that's a plus. I
>> always do anyways for ergonomics reasons, and maybe so should you.
>>
>> This approach compares well to a proper laptop if all you'll be needing
>> is a terminal anyways.
>
> That's fairly similar to how I've been handling things. When I
> travel domestically I do so with homebrewed netbook-like devices
> cobbled together from SBCs with commodity tablet-sized display
> panels and USB mini-keyboards obtained from inexpensive tablet
> cases. I'm a little uneasy trying to cross international borders
> with homemade computers though, so I've resorted to using very cheap
> "burner" mini-laptops that I won't be too upset if I have to ditch
> (I tend to keep one in checked luggage and one in my carry-on in
> case that happens). Most recently I've been using the Fusion5
> lapbooks which run around us$160 and can run a fairly unmolested
> Debian install with a mainline Linux kernel, but Chromebooks are
> another popular choice for this among my colleagues who take similar
> measures.
>
> I've also invested in bulk packs of tamper-evident evidence bags
> large enough to put my devices in, and rolls of tamper-evident
> serial number labels to cover all ports on them. These are obviously
> not foolproof, but they increase the amount of time an adversary
> needs to muck with my hardware and still go undetected (I bring a
> stack of bags, so that when I go out to dinner I can put my devices
> in a fresh bag before putting that in the not-terribly-trustworthy
> safe in my hotel room).
>
> And as mentioned elsewhere in the thread, I too have determined that
> a good, strong memorized password/passphrase is a safer choice to
> bring across borders than an SSH key when it comes to having a way
> to bootstrap my actual keys once I reach my destination. It's about
> the only time I SSH with a password (been meaning to set up a second
> sshd specifically for this with some sort of port-knocking scheme so
> it's not easily discoverable by all the brute-forcing portscanners
> out there, and then I can leave my normal sshd set for key-only
> auth). I also tend to make short-lived keys I'll use while
> travelling and yank their access as soon as I get home, just for
> good hygiene.
>
> Of course, travel into mainland China adds an extra layer of fun
> here, but for the moment it's still possible to use a wireless modem
> or phone tether with a SIM for a non-Chinese mobile provider on an
> international roaming plan to get around the GFW block for SSH and
> VPN protocols.
> --
> Jeremy Stanley
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 949 bytes
> Desc: Digital signature
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/1730aa4a/attachment-0001.sig>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 21 Dec 2017 20:49:08 +0100
> From: Natanael <natanael.l at gmail.com>
> To: John Levine <johnl at iecc.com>
> Cc: Cryptography Mailing List <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] Bitcoin, fork you very much
> Message-ID:
> <CAAt2M1_ZiTO43B3XaUP8bHmq2UGmH_=yH-_tTbQuShAwMQt3ag at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Den 21 dec. 2017 20:33 skrev "John Levine" <johnl at iecc.com>:
>
> Let's say I'm with the Chinese government and decide that I am tired
> of people evading currency controls and money laundering with Bitcoin.
> So we adjust the Great Firewall of China to block port 8333. We also
> add some MITM proxies that take newly mined blocks from the Chinese
> side, rewrite them to put the newly mined btc into government-approved
> wallets, fill up the blocks with transactions from outside China, and
> send them along.
>
>
> Blocks are considered valid if;
>
> * The syntax is correct for the header and for all transactions. The header
> includes a Merkle tree hash of the transactions.
> * If all values are within the correct limits, such as that the time of one
> block may not be too far back or into the future compared to the prior one.
> * If the miner's "coinbase transaction" is valid, that first transaction in
> the block in which the miner claims the reward and fees to his own address.
> He can't claim a larger payout than the available reward + fees in the
> transactions bundled in the block.
> * If all transactions only try to claim valid unspent transaction outputs
> from previous transactions, and if they follow all the scripting rules
> correctly (different address formats enforce different scripts), and if
> outputs are not larger than the inputs.
>
> And critically, where your idea fails:
>
> * If the proof of work is valid, meaning that the integer representation of
> SHA256(SHA256(block header)) is less than the current mining difficulty
> target value.
>
> Changing the coinbase transaction to steal the coins changes the Merkle
> tree hash in the header and thus invalidates the proof of work, because the
> header hash changes too - randomly. With a very very tiny probability to be
> valid PoW.
>
> (Note that the above criteria are not complete, there are more factors
> involved. But they're sufficient to describe the concept.)
>
> It's relatively much easier to just attempt to isolate your people from any
> cryptocurrency nodes.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/5105e84a/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 21 Dec 2017 12:40:22 -0800
> From: Tom Mitchell <mitch at niftyegg.com>
> To: grarpamp <grarpamp at gmail.com>
> Cc: Crypto <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] Bitcoin theft and the future of
> cryptocurrencies
> Message-ID:
> <CAAMy4USjJZrRGzVYUX=di8pob1NJCHtHSzTvdr+yd8BZWaB2Hg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>> On Wed, Dec 20, 2017 at 5:37 PM, grarpamp <grarpamp at gmail.com> wrote:
>>
>> On Wed, Dec 20, 2017 at 2:47 PM, Tom Mitchell <mitch at niftyegg.com> wrote:
>>>> Cryptocurrency is the new cash.
>>>
>>> Missing/Omitted in this thread is a mention of quantum computing vs.
>>> blockchain.
>>>
>>> At first quantum computing will be only available to nation states and
>>> monster corporations.
>>> Will they play nice? Then there may be AI discovered insights into
>> existing
>>> methods with
>>> or without quantum computing.
>>> see Programming Pearls by Bentley or as we all know "It is easy is you
>> know
>>> how".
>>
>> To the extent Q / AI are ranked as legit threats, then the same level
>> of efforts should be being thrown into deploying Post Q/AI cryptocoin,
>> and serious questions should be lodged and asked of those that don't.
>>
>
> On the quantum computing side... it is here in the context of the
> life of investments mod the ability to move from a pre-Q chain to a post-Q
> chain.
>
> https://www.technologyreview.com/s/609451/ibm-raises-the-bar-with-a-50-qubit-quantum-computer/
>
> It does not take AI to add new twists to computation.
> https://www.technologyreview.com/s/609193/new-twists-in-the-road-to-quantum-supremacy/
> If we are lucky "quantum supremacy stuff will be overhyped and
> misunderstood"....
>
>
> --
> T o m M i t c h e l l
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/442ff8ea/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 22 Dec 2017 00:27:50 -0500
> From: grarpamp <grarpamp at gmail.com>
> To: cryptography at metzdowd.com
> Cc: tor-talk at lists.torproject.org
> Subject: [Cryptography] Zcash 2nd Ceremony Call for Review /
> Participation, @Snowden EFF ACLU Privacy Updates
> Message-ID:
> <CAD2Ti2_QBdN=PnUqFA5v06RR4=95bbjYTnbWbHf=OcA_4YicZw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> The Zcash Foundation’s Powers of Tau Ceremony
>
> The Zcash Foundation is excited to announce that we have already begun
> coordinating a Powers of Tau ceremony. Because the results of this
> ceremony are intended for general public use (not just for Zcash), we
> want to involve as many diverse participants as possible
> (professionals, startups, enterprises, and even just ordinary members
> of the community).
>
> https://z.cash.foundation/blog/powers-of-tau/
> https://lists.z.cash.foundation/pipermail/zapps-wg/2017/thread.html
> https://eprint.iacr.org/2017/1050
> https://github.com/ZcashFoundation/powersoftau-attestations/
> https://chat.zcashcommunity.com/channel/mpc
> https://github.com/ebfull/powersoftau/
>
> https://z.cash/tag/sapling.html
>
> https://z.cash/technology/zksnarks.html
> https://z.cash/technology/paramgen.html
> https://z.cash/blog/generating-zcash-parameters.html
>
> https://twitter.com/Snowden
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 21 Dec 2017 17:21:00 -0500
> From: Jerry Leichter <leichter at lrw.com>
> To: Patrick Chkoreff <patrick at rayservers.net>
> Cc: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <FD53C11B-3A02-48F6-ACD4-3776DF8EDA25 at lrw.com>
> Content-Type: text/plain; charset=us-ascii
>
>> The border crossing scenario just got more difficult. If you copy
>> anything to the laptop, and then try to erase it using software
>> techniques only, there is no way to be sure that it's gone.
> Correct. As an interesting datapoint: Apple's MacOS has a Disk Utility that does all kinds of low-level stuff on a disk. It used to provide a Secure Erase option, which erased everything on a hard drive using well-known techniques. It no longer does: Apple no longer sells any devices with "spinning rust" disks, just SSD's; and there is no secure way, even if you are the OS/driver author, to do a secure erasure.
>
> Note that this is problem arises *because SSD's implement a backwards-compatible interface to a disk*. The underlying technology is actually not a great match to the way disks work; there's a lot of code inside and SSD to make the device "look like" a disk. The underlying layer *could* securely erase all the contents; and an interface to request erasure *could* be provided. Such interfaces have been proposed and perhaps even implemented, but as far as I know none has actually been implemented in a mass-market product. (It would not surprise me to learn that parts with this capability exist in specialized markets, e.g., for the military. The prices would likely be extremely high.)
>
> For the rest of us, probably the best thing to do is to encrypt everything before it goes to the device. Destroy the key, and the device is logically erased instantly. (Both iPhones and some Android devices actually do this.)
>
> Of course you run into the "turtles all the way down" problem: If you store the key on the device itself ... how do you erase it when you can't control what gets written where?
>
>> I suppose now it's safest just to shred the SSD physically before you
>> return from the trip. Either return with no hard drive or install a spare.
> While the information may be *present* on the drive, getting it out requires specialized hardware and techniques. How valuable is this information? How serious an attack are you concerned about having to survive?
> -- Jerry
>
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 21 Dec 2017 22:26:42 +0000
> From: Peter Gutmann <pgut001 at cs.auckland.ac.nz>
> To: Jeremy Stanley <fungi at yuggoth.org>, "cryptography at metzdowd.com"
> <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <1513895198544.66167 at cs.auckland.ac.nz>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jeremy Stanley <fungi at yuggoth.org> writes:
>
>> When I travel domestically I do so with homebrewed netbook-like devices
>> cobbled together from SBCs with commodity tablet-sized display panels and USB
>> mini-keyboards obtained from inexpensive tablet cases.
>
> How do the TSA guys react when they open your bag and see a pile of strange
> wired-together electronics?
>
> Peter.
>
>
> ------------------------------
>
> Message: 13
> Date: Thu, 21 Dec 2017 22:32:24 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <20171221223223.GA13067 at yuggoth.org>
> Content-Type: text/plain; charset="utf-8"
>
>> On 2017-12-21 22:26:42 +0000 (+0000), Peter Gutmann wrote:
>> [...]
>> How do the TSA guys react when they open your bag and see a pile
>> of strange wired-together electronics?
> [...]
>
> So far it's gone through the X-ray conveyor zipped up (I have it
> strapped into a modified fabric CD organizer for convenience) at
> least a couple dozen times and not raised any red flags. I expect it
> looks pretty much like a typical tablet or netbook on profile.
> --
> Jeremy Stanley
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 949 bytes
> Desc: Digital signature
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/eac1a1fa/attachment-0001.sig>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 21 Dec 2017 23:05:25 +0000
> From: Robin Wood <robin at digi.ninja>
> To: John Denker <jsd at av8n.com>
> Cc: Cryptography Mailing List <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] paragraph with expected frequencies
> Message-ID:
> <CALmccy6bypD0sZ8R8VN25ZP44w6pB3409a=fCTk5k2+5LQH0gA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, 21 Dec 2017, 19:31 John Denker via cryptography, <
> cryptography at metzdowd.com> wrote:
>
>>> On 12/20/2017 02:02 AM, Robin Wood wrote:
>>> I'm working on a bit of crypto with my young daughter and we are about to
>>> look at frequency analysis. Are there any short UK English paragraphs
>> where
>>> the frequency of letters is about what you would expect based on
>> frequency
>>> charts? i.e. E then T, A and O.
>>>
>>> Bonus if the digraphs are also roughly in order.
>>>
>>> I want to count the letters by hand so don't want anything too long and
>> it
>>> has to be PG content.
>>
>>
>> The question is both trivial to answer, and impossible.
>>
>> It is trivial for linguistic and cryptological reasons:
>> Almost any reasonably large sample of English will
>> display characteristic English letter-frequencies.
>>
>> This is not mathematically guaranteed; it is just a
>> known property of natural language.
>>
>> It is an important property. Frequency analysis is
>> not a known-text or chosen-text attack, where you
>> know a_priori that the text has the exact "expected
>> frequencies". It works for any halfway-reasonable
>> text. This is the fatal weakness of any monoalphabetic
>> substitution cipher.
>>
>> ==========
>>
>> In contrast, there are good mathematical reasons why
>> no finite sample will display the "expected frequencies"
>> exactly.
>>
>> Frequency is a type of probability. There are lots of
>> probabilities in this world, and lots of frequencies.
>> In this case we are particularly interested in the
>> /population/ i.e. all possible texts, which is an
>> effectively infinite set, and various finite /samples/
>> that might be drawn from the population. Statisticians
>> give these terms technical meanings which unfortunately
>> diverge from the meanings in any other context, but
>> let's stick with the statistical definitions here.
>>
>> The frequencies observed on any sample will converge
>> to the frequencies on the population in the limit
>> of large sample-sizes ... but we are talking about
>> convergence in the limit, not equality for any finite
>> sample.
>>
>> For any finite sample, /statistical fluctuations/
>> guarantee that the sample frequencies are expected
>> to differ from the population frequencies. You can
>> use properties of the population to predict the
>> distribution of fluctuations (as a function of
>> sample size) if you want.
>>
>> The larger the number of observables (e.g. the 26
>> different letter frequencies) the smaller your
>> chance of seeing the "expected frequencies" exactly.
>>
>> On the other hand, the point of the exercise is
>> statistical /inference/. Frequency analysis allows
>> you to infer that the text is English, as opposed
>> to gibberish. With a reasonable-sized sample, you
>> can infer this with high confidence _despite_ the
>> fluctuations. The confidence will never be exactly
>> 100%, because the tail of the English distribution
>> will overlap the tail of the gibberish distribution
>> "somewhat", but this is not a problem in practice.
>>
>> Even if you could hunt up a sample that did have
>> the exact "expected frequencies", it would be very
>> unwise to use it as the basis of a lesson, because
>> it would teach a wrong lesson about statistical
>> fluctuations and statistical inference.
>>
>> ==> A much better lesson would be to repeat the
>> experiment with a few different sample-sizes from
>> the same source, to demonstrate the mathematical
>> point about fluctuations and convergence ... and
>> then compare a few disparate sources (e.g. Dickens
>> versus Rowling), to demonstrate the linguistic
>> point about near-invariance of the frequencies.
>> Thirdly, histogram a random process (diceware)
>> as a control.
>>
>> Counting using tally-marks (a) is easier and (b)
>> constructs a histogram on the fly. Plot a large
>> sample with N subsamples, using N colors of ink,
>> all on the same cumulative histogram, so you can
>> see the fluctuations and the convergence at a glance.
>>
>> Digraphs converge 26 times more slowly, for obvious
>> reasons, and so require much larger samples. This
>> should come several turns later on the pedagogical
>> spiral.
>>
>
>
> Oh well, was worth a try. I'll grab some cuttings from different newspapers
> and start with those and see how we go.
>
> Start with some counting by hand then write some code to do bigger texts
> and create graphs.
>
> Might be interesting to try to find texts that do fit the expected
> frequencies, maybe a discussion of the Queen jumping in a Zumba class :)
>
> Robin
>
> Robin
>
>
>
>> _______________________________________________
>> The cryptography mailing list
>> cryptography at metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171221/1e64feb9/attachment-0001.html>
>
> ------------------------------
>
> Message: 15
> Date: 21 Dec 2017 18:11:11 -0500
> From: "John Levine" <johnl at iecc.com>
> To: cryptography at metzdowd.com
> Cc: guninski at guninski.com
> Subject: Re: [Cryptography] Lakestone Bank and Trust Just Made A
> Problem, Oopsie
> Message-ID: <20171221231111.91A97186C322 at ary.qy>
> Content-Type: text/plain; charset=utf-8
>
> In article <20171221150728.GC844 at sivokote.iziade.m$> you write:
>> On Wed, Dec 20, 2017 at 10:33:20PM -0500, grarpamp wrote:
>
>>> https://www.facebook.com/LakestoneBank/
>
>> This greedy bank well might kill herself, possibly downing large
>> amount of the rest of Ponzi scheme banks.
>> It is enough critical (possibly not large) part of their lusers
>> to ask their money back.
>
> That's completely ridiculous. This is a small town bank in Lapeer MI,
> an exurb of Detroit. It has been around since 1902 has grown modestly
> by buying and merging other small banks nearby including one that was
> founded in 1898. It has under $600 million in assets, which is quite
> small, and a 10% capital ratio and 10% return on equity, which make it
> a very healthy little bank. I expect that most of their customers
> live within driving distance of one of their offices.
>
> They probably consider speculating on Bitcoin to be gambling, which by
> any normal definition is exactly what it is. It is not unusual for
> banks to fire customers who they believe are engaging in excessively
> risky financial behavior. The only response I have seen to the letter
> from the bank is flaming on reddit. I see no evidence that any of the
> bank's other customers care, or have even noticed.
>
> R's,
> John
>
> PS: Once again, I would encourage people who know nothing about
> economics, and aren't willing to do the most basic research, to
> refrain from economic pontification.
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Thu, 21 Dec 2017 18:54:46 -0500
> From: Patrick Chkoreff <patrick at rayservers.net>
> To: Cryptography <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <faf66ca0-3a9f-e8ea-a953-11a0ecdb3914 at rayservers.net>
> Content-Type: text/plain; charset=utf-8
>
> Jerry Leichter wrote on 12/21/2017 05:21 PM:
> ...
>> For the rest of us, probably the best thing to do is to encrypt
>> everything before it goes to the device. Destroy the key, and the
>> device is logically erased instantly. (Both iPhones and some Android
>> devices actually do this.)
>
> Right.
>
>> Of course you run into the "turtles all the way down" problem: If
>> you store the key on the device itself ... how do you erase it when
>> you can't control what gets written where?
>
> Right. I can tediously ponder any number of software counter-measures,
> but they're all vulnerable.
>
>>> I suppose now it's safest just to shred the SSD physically before
>>> you return from the trip. Either return with no hard drive or
>>> install a spare.
>
>> While the information may be *present* on the drive, getting it out
>> requires specialized hardware and techniques. How valuable is this
>> information? How serious an attack are you concerned about having to
>> survive? -- Jerry
>
> My own threat model is not terribly demanding. I mostly just want to
> protect GPG and SSH private keys.
>
> I think you have to physically destroy the device. It's the only way to
> be sure. Carry only a disposable device, as Nico and Jeremy have
> discussed, such as a Raspberry PI and SD card. I think you can just
> destroy the SD card, as I suspect no traces of information will remain
> on the PI itself, discounting 4 degree Kelvin attacks on RAM.
>
>
> -- Patrick
>
>
> ------------------------------
>
> Message: 17
> Date: Fri, 22 Dec 2017 11:29:09 +1100 (EST)
> From: Dave Horsfall <dave at horsfall.org>
> To: Cryptography List <cryptography at metzdowd.com>
> Subject: [Cryptography] Happy birthday, Tommy Flowers!
> Message-ID: <alpine.BSF.2.21.1712221126380.27626 at aneurin.horsfall.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Tommy Flowers MBE was born on this day in 1905; an electrical and
> mechanical engineer, he designed Colossus, arguably the world's first
> electronic computer, which was used to break the German "Lorenz"
> high-level cipher (not Enigma, as some think).
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>
>
> ------------------------------
>
> Message: 18
> Date: Fri, 22 Dec 2017 18:07:30 +0900
> From: Aimable Niyikiza <niyimunyura at gmail.com>
> To: cryptography at metzdowd.com
> Subject: [Cryptography] Cybersecurity Regulation for Crypto Exchanges
> Message-ID:
> <CACE-jhYfHkByUuUbg5BB28ZLjAVJCNPRZFC_nhpHJBeZJKByiQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> With the rise of hacking incidents (whether real or staged) of
> cryptocurrency exchangies and wallet companies, it seems that there needs
> to be a framework aking to PCI-DSS for these companies to follow.
>
> Eg:
> https://techcrunch.com/2017/12/20/etherdelta-suspends-service/?ncid=rss&utm_source=tcfbpage&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29&sr_share=facebook
>
>
> Users need to know that their money/tokens are kept responsibly.
>
> I'm thinking of a non-profit auditing organization that would check if they
> follow the most basic Cybersecurity practices.
>
> Any ideas?
>
> --NA
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171222/ddc6218d/attachment-0001.html>
>
> ------------------------------
>
> Message: 19
> Date: Fri, 22 Dec 2017 10:21:57 +0100
> From: Gé Weijers <ge at weijers.org>
> To: Patrick Chkoreff <patrick at rayservers.net>
> Cc: Cryptography <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] Rubber-hose resistance?
> Message-ID: <1677840623069639153 at unknownmsgid>
> Content-Type: text/plain; charset="UTF-8"
>
>> [...] as I suspect no traces of information will remain
>> on the PI itself, discounting 4 degree Kelvin attacks on RAM.
>>
>
> Desoldering the RAM while maintaining a low temperature should be interesting.
> The original raspberry pi used a PoP package, which would make it even
> more interesting.
>
> Gé
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
> ------------------------------
>
> End of cryptography Digest, Vol 56, Issue 22
> ********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171222/82ae9d70/attachment.html>
More information about the cryptography
mailing list