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

[grarpamp]

On Mon, Oct 10, 2016 at 10:55 PM, Zooko Wilcox-OHearn
 wrote:
> open-source implementations

> Jump in! The worst that can happen is that you get the fun and
> education of implementing an interesting new proof-of-work algorithm.
> :-)

Zcash is Linux only. That's not good for diversity, adoption, code
exposure, etc.
Here one place people can jump in the (only known to date?) effort to
fix that...

# net-p2p/zcash: create initial port and package
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213930
___
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)

[grarpamp]

I'd agree that "forums" are a poor choice.
They're magnets for masses of the clueless,
which is fine for that purpose. And they're
heavyweight, captive, and exploitable.
Lists can be archived, replicated, distributed,
offlined, searched with any MUA, etc. +1.

(A bidirectional gateway to list, with [un]subscribe,
and only sending message content not all the
damn forum bling, and proper threading of headers,
might be acceptable. However I don't know of any
forum that has that capability and care for email.)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] RNG Breakthrough: Explicit Two-Source Extractors and Resilient Functions

[grarpamp]

Let's do another 100 post round on the favorite subject shall we...
because serious RNG is serious.

Academics Make Theoretical Breakthrough in Random Number Generation
https://news.ycombinator.com/item?id=11719543
https://threatpost.com/academics-make-theoretical-breakthrough-in-random-number-generation/118150/
Explicit Two-Source Extractors and Resilient Functions.
http://eccc.hpi-web.de/report/2015/119/

We explicitly construct an extractor for two independent sources on n
bits, each with min-entropy at least logCn for a large enough
constant~C. Our extractor outputs one bit and has error n−(1). The
best previous extractor, by Bourgain, required each source to have
min-entropy 499n.

A key ingredient in our construction is an explicit construction of a
monotone, almost-balanced boolean function on n bits that is resilient
to coalitions of size n1−, for any 0. In fact, our construction is
stronger in that it gives an explicit extractor for a generalization
of non-oblivious bit-fixing sources on n bits, where some unknown n−q
bits are chosen almost \polylog(n)-wise independently, and the
remaining q=n1− bits are chosen by an adversary as an arbitrary
function of the n−q bits. The best previous construction, by Viola,
achieved q=n12− .

Our explicit two-source extractor directly implies an explicit
construction of a 2(loglogN)O(1)-Ramsey graph over N vertices,
improving bounds obtained by Barak et al. and matching independent
work by Cohen.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] USG-Apple - 3/22/16 Hearing Procedures, Add 3 USGs

[grarpamp]

On 3/18/16, Jeffrey Walton  wrote:
> It sounds like its turning into a circus sideshow:
>
> ... in addition to Courtroom 4, there will be additional overflow
> rooms in which the hearing will be shown on video screens. All of
> these rooms together can accommodate up to a total of 324 spectators.
> Admission tickets for these seats will be distributed outside the
> courthouse starting at 7:00 a.m. on March 22, 2016.
>
> I hope it gets good media coverage, like the OJ Simpson trial. If the

With 360 possibly pro Apple seats, odds are someone there is
bound to be recording at least audio and will release it anonymously
in full immediately that night.

> government sides with the government (what a surprise that would be) I
> hope the US citizen riot orders of magnitude larger than Rodney King.

Could be interesting how the Apple-Customer relationship plays out.
Particularly if Apple [has been] conditioning them right.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [cryptome] Crypto Beguilement

[grarpamp]

On 2/21/16, Michael Best  wrote:
> What, if anything, could the government do involving crypto that you
> wouldn't see as nefarious or two faced?

Um, as crypto can be done anywhere by any individuals / consensus / delegee.
Question is really, is any govt (any specific extant one, or in theory),
valid / valuable / trusted, to give any such doing to, given above.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Cryptome’s searing critique of Snowden Inc.

[grarpamp]

On 2/14/16, Henry Baker  wrote:
> Can someone please post a link to the .mp3 or .mp4 of this interview?

youtube-dl https://api.soundcloud.com/tracks/246093198
Interview with Cryptome (2016-02-06)-246093198.mp3
sha1: 2cf21291e0190dcc2b6c1fa2587994546311ea0f
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Paris Attacks Blamed on Strong Cryptography and Edward Snowden

[grarpamp]

On Wed, Nov 18, 2015 at 8:51 PM, Ted W.  wrote:
> And yet, we find that the Paris attackers did not communicate via
> encrypted channels for most of their planning. Surprise surprise:

Which means absolutely nothing to these anti crypto people.
And is no excuse for you to quit deploying crypto and fighting them.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Paris Attacks Blamed on Strong Cryptography and Edward Snowden

[grarpamp]

On Thu, Nov 19, 2015 at 1:21 AM, mtm  wrote:
> how did hominids manage prior to crypto?

Papyrus sealed in wax via trusted courier with promise of
sword to neck for peeking, capture, or failed delivery.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Paris Attacks Blamed on Strong Cryptography and Edward Snowden

[grarpamp]

On Tue, Nov 17, 2015 at 11:06 AM, John Young  wrote:
> Wheedling about crypto and Snowden diverts from CIA Director's full speech
> and broader critique. CIA version omits Q
>
> http://csis.org/files/attachments/151116_GSF_OpeningSession.pdf

> https://www.schneier.com/blog/archives/2015/11/paris_attacks_b.html
> https://theintercept.com/2015/11/15/exploiting-emotions-about-paris-to-blame-snowden-distract-from-actual-culprits-who-empowered-isis/
>
> fierce blame for the carnage is being directed toward American
> whistleblower Edward Snowden and the spread of strong encryption catalyzed
> by his actions. Now the Paris attacks are being used an excuse to demand
> back doors

http://www.wired.com/2015/11/paris-attacks-cia-director-john-brennan-what-he-gets-wrong-about-encryption-backdoors/
DNI et al... looking and waiting for "the perfect example"... cue the
911 conspiracies...

http://techcrunch.com/2015/11/17/the-blame-game/
So let’s not be taken in by false flags flown by anonymous officials
trying to mask bad political decision-making. And let’s redouble our
efforts to fight bad policy which seeks to entrench a failed ideology
of mass surveillance — instead of focusing intelligence resources
where they are really needed

http://www.wired.com/2015/11/after-paris-encryption-will-be-a-key-issue-in-the-2016-race/

http://www.theverge.com/2015/11/16/9742182/uk-surveillance-paris-attacks
http://www.dailymail.co.uk/news/article-3319037/We-spies-powers-need-says-LORD-CARLILE.html
"We MUST now give our spies the powers they need", says LORD CARLILE.
https://en.wikipedia.org/wiki/Enabling_Act_of_1933
The Enabling Act, when used ruthlessly and with authority, virtually
assured that Government could thereafter constitutionally exercise
dictatorial power without legal objection.
They offered the possibility of friendly co-operation, promising not
to threaten the Lawmakers, the President, the States or the Churches
if granted the emergency powers.

http://www.ibtimes.com/paris-terror-attack-intelligence-failure-not-snowdens-fault-break-down-communication-2185255
Intelligence Failure Is Not Snowden’s Fault But A Break Down Of
Communication and Cooperation

http://www.nytimes.com/2015/11/17/world/europe/encrypted-messaging-apps-face-new-scrutiny-over-possible-role-in-paris-attacks.html
Encrypted Messaging Apps Face New Scrutiny Over Possible Role in Paris Attacks
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Paris Attacks Blamed on Strong Cryptography and Edward Snowden

[grarpamp]

On Tue, Nov 17, 2015 at 1:39 PM, Givon Zirkind  wrote:
> imho, the crypto involved is not the issue.  not having boots on the ground,
> good intel, good spies who can walk and talk like the enemy, is the real
> issue.

Exactly. Governments have had at least 15 years to strap those boots,
and certainly have some good ones. These days it's probably just
as interesting as USA vs. USSR in that regard... plots, schemes,
double and triple agents... the spy game.

It's interesting what other perhaps complementary and/or parallel
forms of intel and boots have sprung up. Though best examples
are surely not seen, wrapped in closeness to government agencies
or other allegiences, and these links cover only one small theatre
among the list of things any agents, actors and mafioso have always
had an interest in... yet one can begin to get the idea... just how
deep does this sort of online game go...

https://twitter.com/TorReaper/status/66126621373218
http://www.ghostsec.org/
http://pastebin.com/search?q=isdratetp4donyfy
https://cpunks.org/pipermail/cypherpunks/2015-November/010940.html

> there was no crypto in the false i.d. papers used to gain entry.
> there is no crypto in exploiting the humanitarian aid being given to syrian
> refugees.  these people operate in unconnected cells.  how much
> communication can there be; once an idea is hatched; a plan formed and; put
> into motion--from a few secret meetings.  esp. since they know enough to
> have to maintain radio silence.

Like volunteering for missionary, cash and a blessing at sendoff
is still a very hard problem to crack. Unless you become confidant
of both Padre and Church itself, or simply become them...

Regardless, if any of this affects your area you should definitely
have your talking points and counter solutions lined up, because
the exposure and fields of play are growing and it's not going away.
Welcome to the connected world.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] a little help with cookies please

[grarpamp]

What is of more crypto / security interest is not bandwidth use
or even domain or path restrictions, but failure of webdevs to
seed and restrict sensitive cookies (like your authenticated
session id's) from and to TLS only sessions.
Well known top100 sites that still have a legacy http mode
fail to do this properly... banks, social, govt, etc.
Even sites that immediately 302 your first hit (or other hits)
over to https thereafter can be found doing it wrong.
Ripe for wifi or wire monitoring based session stealing.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] CNSS Issues Memo on Shift to Quantum-Resistant Cryptography

[grarpamp]

On Mon, Aug 17, 2015 at 12:53 PM, John Young j...@pipeline.com wrote:
 CNSS Advisory Memo on Use of Public Standards for Secure Sharing of
 Information Among NatSec Systems 08/11/15

 https://www.cnss.gov/CNSS/openDoc.cfm?DLuhIVBMUGJh7R8iXAWwIQ==

 iang wrote:
 John, that document blocked due to session variable or something.  Is there 
 an open copy?

It's here (and on cryptome under the official filename)...
https://www.cnss.gov/CNSS/issuances/Memoranda.cfm
CNSS_Advisory_Memo_02-15.pdf

All ur linkclicks are...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Possible SigInt Metadata Dump Files Circulating

[grarpamp]

No evidence, calling baloney on this one.
The theory is fun though.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Mixing multiple password hashing: Crypto Blasphemy or Useful approach?

[grarpamp]

Is this not the old chained crypto argument? It comes down to whether
or not you believe is, or will be, an attack known or unknown upon
any singular or combined crypto choice. If you do believe, which
is reasonable given prior crypto has been broken and that all
knowledge is never public, then compose your own function of different
crypto designs (ex: TrueCrypt chained three). If not, go with
whatever single crypto looks good and serves the design of your
application. It's just a function... with combined odds against
breaks, and it's good to design against known expenses of the
adversary like time and memory. Just don't break it while implementing
it.

No useable KDF will help if 12345 is the passphrase. And 40 random
of printable ascii chars are stronger than any 256 bit KDF.

Seems to me it's not better KDF that's needed, but better memory.
http://en.wikipedia.org/wiki/Simon_(game)
http://www.recordholders.org/en/list/memory.html

Or just write it down on the other side of the airgap.

If that's not doable, then you resort to the KDF bits game for
expected weak inputs. The tradeoff there is useability. Nobody is
going to wait five minutes for their idiot passphrase of 12345
to go through some elite, but ultimately useless in that case, KDF.
Password checkers can enforce some minimum bits there.

Regardless, you still have the law, the rubber hose, and your own
backup plan to contend with. Good luck.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Equation Group Multiple Malware Program, NSA Implicated

[grarpamp]

 Here's an interesting comparison.  Most academic cryptographers believe
 that the NSA has lost its lead:  While for years they were the only ones
 doing cryptography, and were decades ahead of anyone on the outside, but
 now we have so many good people on the outside that we've caught up to,
 and perhaps even surpassed, the NSA.  I've always found this reasoning a
 bit too pat.  But getting actual evidence has been impossible.

 What evidence is there for this?

 Snowden saying encryption works.

This is probably quite true... from his particular vantage/access point
and social network. Yet however much we may know about that side
being relatively open and shary and the capabilities there, it is not an
exclusive answer to the crypto question. None of the Snowden docs to
date are or show any real details about the crypto side of the house. He
either had no interest (unlikely), had no time, found it too risky (whether
to pull off without being caught, or over concern about some element of
grave damage), or simply had no access.

 FBI complaining about going dark, we need backdoors - they only ever
 complain at that level as proxy for NSA, and same complaint is repeated in
 rapid succession in UK, DE.

These sort of things may be important indicators. Yet to prove
them as such you'd also have to analyse the history of
FUD making, grab attempts and so on to interpret.

It could be that selective crypto is not dark, but merely expensive
to scale into being see all as desired with the old in clear. So
you would have to analyse the costs there. Electricity, rainbow
disk storage, real estate, cooling. How do you know the disk
makers and their suppliers do not have black wing budgets. Or
that there is not a multi billion fab lab buried under some mountain
powered by a ground radiator / aquifer cooled nuke reactor?

 This is exactly how organizations win over smart individuals:
 They build a database of expertise over many years, and they are
 patient and can keep at it indefinitely.

Yes, that's one... who is tracking where all the brilliant maths and
others go after high school? The student names in known friendly
colleges and programs? The ones that seem to drop from the
public scene? What media is publishing interviews with them?
Where are known adversary retirees that may have something
to say when invited?

 It's not that I have evidence the other way.  We just don't know.

 At one level, this all comes down to your model of science.
 ...
 thinking of the question as a murder investigation - clues, hypotheses,
 correlations, etc.

To know the adversary you must continual analyse all potential
aspects, and not just aspect itself but their inputs, dependencies
and output/result chains. Then maybe you can answer some
questions. After all, the adversary is doing analysis upon you.

 Right.  I'm surprised Android sells any phones in USA market.

It's surprising that maybe no one has yet reverse engineered the binary
blobs/drivers in android to provide a fully open software stack there.
And although more difficult, same goes for the firmware blobs.
Regardless of effectiveness, it would show market demand.

 New models for large
 corporations only started to arise in the late 1960's, with the development
 of so-called knowledge organizations.

Knowledge, and knowledge dichotomy within capacity of biology as
a whole to adapt evenly, seems quite a potential for scary outcomes...

http://yro.slashdot.org/story/15/02/17/2229240/oregon-residents-riled-over-virtually-staff-free-data-centers-getting-tax-breaks
http://science.slashdot.org/story/15/02/17/030208/game-theory-calls-cooperation-into-question
http://yro.slashdot.org/story/15/02/17/0025237/att-to-match-google-fiber-in-kansas-city-charge-more-if-you-want-privacy
http://tech.slashdot.org/story/15/02/16/2332217/the-software-revolution

 In sum, I'd say they are ahead in the pure math, but you'd be hard
 pressed to find an area where it mattered.

 Maybe.  It's really impossible to say.  Two days ago, I would probably
 have agreed with you.  Now ... I'm not so sure.

As with Google, they hire a lot of Maths and others, and have been
at it for decades longer. Even generations of maths born into now.

There is too much silence from these workers.
Especially when society could probably get along just
as well without so many organizational level secrets
everywhere (wars), and now potentially against peoples
if you believe that sort of thing.

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

Re: [cryptography] [Cryptography] Equation Group Multiple Malware Program, NSA Implicated

[grarpamp]

From someone failing to send to list:
 Or he actually got those docs ...

Possible, but you would expect crypto research to be
well compartmented from legal, sigint and offensive ops
that appear to be the sole scope of the known docs.
If research does posess a break, maintaining that secret
while producing politically/operationally useful decrypts
would be harder to manage.

 but the journalists he entrusted them to have decided not to release them.

You can always bury / escrow multiple copies in multiple locations
known only to you in case you need them later. Hard to
believe this was not forseen and done given history of media
with prior leaks.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] ODNI Counsel: Governments Want Accessible Crypto from Business

[grarpamp]

 http://en.wikipedia.org/wiki/USA_Freedom_Act
 http://www.lawfareblog.com/2015/02/the-lawfare-podcast-episode-109-robet-litt-on-us-surveillance-policy-one-year-after-ppd-28/
 http://www.lawfareblog.com/2015/02/live-bob-litt-speaks-at-brookings-on-intelligence-and-surveillance-reform/

Related lawfare:
https://www.eff.org/deeplinks/2015/01/section-215-patriot-act-expires-june-congress-ready
https://www.eff.org/deeplinks/2015/02/first-government-acknowledges-limits-section-215
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] ODNI Counsel: Governments Want Accessible Crypto from Business

[grarpamp]

On Sat, Feb 7, 2015 at 8:42 PM, John Young j...@pipeline.com wrote:
 ODNI counsel Robert Litt is optimistic cryptographers will devise secure
 encryption which provides government access, it's what many governments  
 want.
 One of the many ways in which Snowden's leaks have damaged our national
 security is by driving a wedge between government and providers and
 technology companies so that some companies that formerly recognized that
 protecting our nation was a valuable and important public service they could
 perform now feel compelled to stand in opposition.

Some award winning slimy statements right there.

Translation:
Govt damaged itself, got caught, is pissed, is trying another sleazy grab.
Corp's sold users/customers out the last 15y, are trying to regain trust
(you've got at least 15y to make up for... so keep standing in opposition,
we'll let you know when you can take a break)
Snowden's a hero

 http://cryptome.org/2015/02/odni-litt-15-0204.pdf
You're all potential other threats, handy right?

http://en.wikipedia.org/wiki/USA_Freedom_Act
http://www.lawfareblog.com/2015/02/the-lawfare-podcast-episode-109-robet-litt-on-us-surveillance-policy-one-year-after-ppd-28/
http://www.lawfareblog.com/2015/02/live-bob-litt-speaks-at-brookings-on-intelligence-and-surveillance-reform/

They still haven't answered? that one simple question about
how having *you* on their disks without a warrant specifically
covering probable cause on *you* to put it there... is constitutional.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] John Gilmore: Cryptography list is censoring my emails

[grarpamp]

On Wed, Dec 31, 2014 at 7:16 AM, John Young j...@pipeline.com wrote:
 http://cryptome.org/2014/12/gilmore-crypto-censored.htm

John(Gnu):

Likely Trilight Zone is not an app (like cspace), it's a service
(like other/similar services they claim to be concerned about
in media-35535.pdf). Best used in the noted conjunction '+' chains.

https://www.trilightzone.org/


CSpace looks like a single hop p2p transport net, with
some API'd apps included.

http://www.anonymous-p2p.org/cspace.html
http://en.wikipedia.org/wiki/Draft:CSpace
https://groups.google.com/d/forum/cspace-users
http://www.mail-archive.com/cspace-users@tachyon.in/
http://board.planetpeer.de/index.php?topic=1852.0
http://board.planetpeer.de/index.php?action=profile;u=41
http://board.planetpeer.de/index.php?action=profile;u=41;sa=showPosts
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] JYA Hash this motherfucker, said math to germ.

[grarpamp]

 K scriben:
 I would like to get back to serious crypto conversations now.  Thank you.

You mean the quarterly circle jerk about random numbers, PKI,
standards, committees, and whatever else gets routinely hashed
to death?

I'd consider models of hashing and signing distributed materials
as a serious and necessary applied crypto conversation. Not
least of why because many of the people on these lists have no
idea how to actually do such things, let alone well.

Being said, there are good crypto talks, code/design reviews,
etc here too.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NSA Attacks on VPN, SSL, TLS, SSH, Tor

[grarpamp]

On Tue, Dec 30, 2014 at 7:17 AM, John Young j...@pipeline.com wrote:
 Cryptome does not pretend to provide illusory security, that is security.
 It is a vile, rotten, corrupt endeavor, like life. Chuckle.
 Visitors, readers, consumers must be skeptical of security, and not rely
 [...]

All due respect to Cryptome, and points well made and taken.
Yet this isn't really an effective response to the issue at hand.
While we should and must be skeptical... until contrary proof
exists we should be taking advantage of all means available
regarding distribution integrity and even provenance and secret
comms if desired. That's hard, it involves some work, and homework.
Yet until such proof, it's probably better than going bare assed to
the Sun.

 Still, Cryptome endorses the continuing struggle to improve citizen
 ...
 common math against the deadly germs.

Indeed.

 One way to do that is to not oversell it, tone down the threats, reduce

Interestingly true in some regards. Yet in the context herein, it's
probably not the place to make a stand. Especially considering
the stand itself is in one's very existance all so long. Is it not?
Oh were there but more of this kind, be they true or not :)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Near-collisions and ECC public keys

[grarpamp]

On Mon, Dec 29, 2014 at 8:18 AM, Florian Weimer f...@deneb.enyo.de wrote:
 To check an OpenPGP fingerprint for correctness, it is sufficient (for
 practical purposes) to compare the leading and trailing eight
 hexadecimal digits, and perhaps a few digits in the middle.

It is, only if you prefer these odds...
16^16/2^64 = 1.00
16^19/2^76 = 1.00

I believe collisions in the former are already well known.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] NSA Attacks on VPN, SSL, TLS, SSH, Tor

[grarpamp]

On Mon, Dec 29, 2014 at 8:20 AM, John Young j...@pipeline.com wrote:
 Hash this motherfucker, said math to germ.

JYA, you, as the original publisher of various and valued datasets...
the responsibility to calculate, sign, and publish said hashes rests with
you alone. Please consult with any trusted parties should you need
assistance in such matters. A future of archivers, disseminators, and
analysts will thank you.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email encryption for the wider public

[grarpamp]

On Thu, Sep 18, 2014 at 10:16 AM, Jonathan Thornburg jth...@astro.indiana.edu
 business to E-mail me a receipt/confirmation/whatever.)  Getting the
 spelling of $spouse's (8-letter, but odd to many people) E-mail correct
 over a poor-quality phone connection is hard enough already!

http://en.wikipedia.org/wiki/NATO_phonetic_alphabet

Caveat lack of UTF-8 coverage...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Email encryption for the wider public

[grarpamp]

On Wed, Sep 17, 2014 at 9:43 AM, Henry Augustus Chamberlain
henryaugustuschamberl...@gmail.com wrote:
 I propose that we use the local part of the email address to store the public 
 key,
 ...
 my email address would be (64 random letters)@gmail.com
 ...
 Somebody not using encrypted emails could still click on your mailto
 link and send you an email, although it will be unencrypted

Putting keys into some_encod...@example.com might cover
some bases related to offline key lookup and message validation.
Most user and system mail tools would need changes to handle
string width and keytype, addressbooks updated, etc. Totally burying
OpenPGP, passphrase and key lookup/use behind a fully integrated
MUA GUI for grandma would work just as similarly well right now today
with no such encoding.

But in the end, all you're doing is covering the message body, and in today's
world that's clearly not enough. No one's yet solving the huge issues
with leaving mail exposed to what is essentially open-for-all-to-inspect central
storage and mail routing. The who's IP talking to who, From To Subject,
daemon headers, etc metadata, when, how much/often, provider logs, someone
sending you unencrypted mail, you giving up your private keys to the
provider or running blobs they provide to you, etc. This is all unfixable with
traditional Email models.

This is why that to really solve anything more than the message body,
you need to go completely nextgen and turn that 'email address' into
an anonymous P2P overlay network node address, run your overlay
client [which supplies a mail/messaging front end] and send/receive
mail through that from/to your usual MTA/MUA/messaging toolchain.

The real work there is in pushing the P2P node count up...
- Research how many users globally might leave their messaging
node up 24x7 for a direct realtime overlay connection with the far
end user@node... 1/10/100/n*1000 million?
- Develop message storage [and forward/poll/expiry] within the
overlay for those that aren't in online mode.
- Determine any hardware limitations and thin client models.

There is an ongoing thread with the subject
 The next gen P2P secure email solution
that contains various people's initial thoughts/framework on this.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Browser JS (client side) crypto FUD

[grarpamp]

On Sat, Jul 26, 2014 at 2:57 PM, Theodore Ts'o ty...@mit.edu wrote:
 On Sat, Jul 26, 2014 at 05:03:46PM +0200, Lodewijk andré de la porte wrote:

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

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

// ianG
// It's like opportunistic security..
// It specifically defeats mass surveillance... This is a valuable thing.

Yes, it's nice and helps. It just needs to come with better
disclaimers. Otherwise companies/providers that remain
silent on their threat models do nothing but tarnish themselves
amongst those that know better. Such silence could backfire.
Whether they get used as an bad example in security presentations,
or something happens to one or more of their users they effectively
sold (or gave) snakeoil to.

 Like it or not, the vast majority of people are using some kind of web
 based e-mail, whether it's GMail or Yahoo Mail or Hotmail, or
 something else.

Please provide link to your source that breaks down Email use by
HTTP, IMAP/SMTP and legacy POP. And their crypted versions.


 I think it's a bit more complicated than you're making it out to be.
 Ultimately, the nearly all of the software that people run come from
 the network, at one time or another.  Even if you are using gpg
 running on your linux laptop, where did you get your copy of gpg and
 the Linux OS?  Odds are, you got it over the network.

The problem is the context of where in the network you got the
software from, and who you're using it with, and who you're trying
to keep in the dark.

If your first install or subsequent updates are from your mail,
storage, or comms central service provider, etc... that's a major
and direct conflict of your security interests. It's why Matasano
objects.  You don't download your OS from your adversary.

On the other hand, if you obtain and use the code independantly
of your provider, or the code creates a disinterested decentral
P2P infrastructure (Freenet, etc)... then you're in a much better
position. You've inserted a layer of independance/abstraction.

Similar to installing gnupg to use independantly...
https://openpgpjs.org/
http://code.google.com/p/crypto-js/
You should be able to download openpgp.js from the code distribution
point, read any audits, check the sig, locally load and permanently
lock it into your browser from your plugins directory. And then
mail providers should develop a consistant RFC based API from which
you interact with them so you don't have to download whatever blob
they claim you need.

Directly trusting codeloading works fine for internal corporate
environments. But it's a really bad idea elsewhere.


Examples of careful differences in security model...

Holds the keys
https://www.hushmail.com/

Provides the code
https://encrypt.to/
https://www.bitaddress.org/
https://brainwallet.github.io/

Browser addon (likely dependant on provider webmail scraping 'API':
remember attempts to scrape providers that did not offer IMAP/POP.)
https://www.mailvelope.com/

Standalone webclient
https://whiteout.io/technology.html
https://www.mailpile.is/
 https://github.com/pagekite/Mailpile

Standalone UI
https://www.enigmail.net/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] List of digital currencies?

[grarpamp]

Any links to a list of digital currencies organized by technology?

ie: Bitcoin has countless forks characterized by nothing more
than adjusting (or not) the operating parameters of the bitcoin.org
code and starting their own genesis. Others may swap out the
hash or crypto functions within that. While useful to list them
all under the aforesaid parent technology 'Bitcoin', they are all
ultimately uninteresting and a waste of time to research.

A real list would group all the digital currencies by genuine differences
in architecture... those archs thus resulting in their suitability to different
applications, capabilities to anonymity, features for centralization/regulation,
etc.

So now you might have
Bitcoin
Paypal, Linden
Some other various coin designs
Currencies that pass serialized 'banknotes' around
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Fri, Jun 20, 2014 at 6:35 PM, Jeffrey Goldberg jeff...@goldmark.org wrote:
 (I hope it is clear that I do not think of this as anything like a practical
 threat to AES.

Of course, 8 rounds at 2^unreachable is not practical.

 I had just remembered this paper, with its enormous data
 requirements when I saw original question.)

 Any (reliable) estimates on how big?

 $10M in drives at consumer pricing will get you a raw 177PB, or 236PB at
 double the space and power. Or $1B for 17EB. Budget is an issue.

 As always, let’s go with the high estimate in the hands of the attacker. We
 are still far far short of the storage requirements for this particular attack
 (and all for less than a 2-bit gain).

 So I think that it is safe to say that all that data storage is not an attempt
 to use the particular attack I cited.

I meant as answer 'estimates on how big' question. Take what we know
about storage, figure in some good efficiencies for the 'storage only' case.
And figure what can be bought and operated year on year per foot. You could
hide/support $1B + $1B/year but $10B/yr would be hard given entire intel
budget is $80B, or $50+B if you drop mil. So...

1) How big can you get within budget?
2) What can you do with it re: a) crypto, or b) otherwise?

https://en.wikipedia.org/wiki/United_States_intelligence_budget
https://en.wikipedia.org/wiki/United_States_Intelligence_Community
http://www.martingrandjean.ch/data-visualization-top-secret-us-intelligence-budget/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] encrypting hard drives (was Re: Shredding a file on a flash-based file system?)

[grarpamp]

On Thu, Jun 19, 2014 at 4:18 PM, Dan McDonald dan...@kebe.com wrote:
 ZFS crypto, closed-source thanks to Oracle, was supposed to address this
 problem.  Its design was to apply crypto in the ZIO path, like it does for
 checksums.  I've not used Oracle Solaris, but apparently ZFS crypto is in
 there and it supposedly works.

And as in the design papers/blogs, Oracle ZFS seems to have some
data that is not encrypted that arguably should be.
https://blogs.oracle.com/darren/entry/zfs_encryption_what_is_on

 And let me state for people wondering, Why isn't it in OpenZFS already?

In the OpenZFS world, you deploy each OS's FDE underneath ZFS.
OpenZFS will likely add native encryption feature flag someday to
satiate those who want per dataset keying, etc... but, thanks to Oracle,
anything post zfs28/zpool5 might not end up interoperating.
https://en.wikipedia.org/wiki/ZFS
http://www.open-zfs.org/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] encrypting hard drives (was Re: Shredding a file on a flash-based file system?)

[grarpamp]

On Thu, Jun 19, 2014 at 6:05 PM, Dan McDonald dan...@kebe.com wrote:
 In the OpenZFS world, you deploy each OS's FDE underneath ZFS.

 For now, yes.  That's what you're stuck with.

That's actually not a problem.

 That blog is 3.5 years old.  I think things have likely improved since then.

Only if customer demand (pay) Oracle for it.

 From what I can tell (and yes, I *am* biased...) only a few in OpenZFS-land
 gives a rat's ass about interoperating with the Lawnmower.

After Oracle pissed on Sun and said fuck you to opensource,
that is expected. The ZFS model and code bulk are open now
and have a home. Check back in a year.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Sat, Jun 7, 2014 at 11:45 PM, Sidney Markowitz sid...@sidney.com wrote:
 I don't know what would make me feel safer - putting the phones in a microwave
 oven with the chance that the door could easily be left ajar, or getting the
 acoustic insulation and masking hum of a refrigerator.

Trust the microwave you tested, right, because you do not know
what quality DSP is pricessing your remaining 5dB audio over
your entire conversation. Or put microwave in fridge ;)
aka: remove battery / crush/displace phone... be happy.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

 (or as Snowden demonstrated, put in a fridge to avoid scrutiny and
 audio capture the best idea.  non-serial tower associations are an
 anomaly alerted and acted upon.)

Faraday cages concept really depend on the freqs they are designed
to inhibit, pressure, sound, radio, optic, etc. Given wide enough freqs,
one cage does not service all.
A fridge has plastec and magnetic gaskets, over maybe 2cm variant
gap, so not a complete EM seal (at whichever specifical freqs).
And grounding issue. But good at human sound deading.
Microwave door shield is closer to cell phone freq shield.
If you cannot simply remove the battery preferably, that is.
As always, test first. And is easy to find phones to test
all phone bands with.
TEMPEST.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Sun, Jun 1, 2014 at 9:45 PM, Cathal (phone)
cathalgar...@cathalgarvey.me wrote:
 What about streaming, which is increasingly used to hold power to account in
 real time? Or other rich, necessarily large media which needs to *get out
 fast*? Big media isn't always frivolous. Even frivolity is important, and a
 mixnet without fun is gonna be a small mixnet.

Would you rather have one 4k video taken from someone's phone
jiggling in their backpocket as they run with blood all over the lens,
ten emails from people in situ known to you, or photodumps from
two balcony photographers... all of which just saw some gov beat
the fuck out of a bunch of sitdown protesters?
Either way, the choice is best left to the sender. Our role is merely
to make good systems, explain their design, options and tradeoffs,
and then carry the data.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

In May 2014 someone wrote:
  p2p is no panacea, it doesn't scale

 I believe it could. Even if requiring super aggregating
 nodes of some sort. Layers of service of the whole
 DHT space. More research is surely required.

 It is not possible to have fast p2p unless:
 - Cable networks collaborate by increasing bandwidth 7 to 8 times

My references to scale were not intended to be about...
bulk bandwidth across such networks (for example, right
now, I2P and Tor are doing well enough to see very low
quality video between their hidden nodes if you get a lucky
path, and well enough for moving large files around in non
realtime). ie: the nodes have bandwidth available.

But about scaling the node (user) count from millions to billions...
No device (or its ethernet) will be able to manage a 10 billion
entry DHT with a handful of keys, addresses and flags per entry.
But if you break it up into some many clusters/hiers/roles of smaller
DHT's, each knowing how to route queries, sort, and pass entries
around, it might work. Once you've assembled your multihop
path from querying the DHT for nodes, actual data transfer
rates should remain similar. (Provided the network clients
know to reserve bandwidth mod the network average hop count,
by throttling the users usage at their own node).

It would be nice to check some numbers on this for the list.
Is there a wiki or paper repository that discusses plausibly
reachable DHT sizes, time needed for DHT ops to resolve,
and management schemes for such clusters/hiers/roles?


[aside: This everyone online, big DHT, end-to-end reachable
model mirrors the internet today as a general purpose tool.
Perhaps sufficient for many rather sensitive tasks.
When the purpose is narrowed, other models may apply.
For messaging (as is the subject), everyone still needs a
unique address. And since msg delivery/pickup must be
reliable, there is a question of redundancy needed to avoid
random msg loss. Which may turn you away from store-forward,
mixes, and unconscious central storage, etc... towards everyone
online, contact them directly over a path or retry later.
Today it seems that general purpose may be better researched
and easier than more exotic means. Question is, is GP sufficient,
after applying any recent GP tech post I2P and Tor's designs?
ie: Some say timing attacks may be mitigated by fixed packet
lengths and adding chaff over links as cover.]
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Fri, May 16, 2014 at 6:01 AM,  tpb-cry...@laposte.net wrote:
  pesky to/from/subject/etc headers.

  Those are hidden by use of TLS.

 weaknesses intrinsic to SMTP discussions?
 Yes, they are hidden in TLS transport on the wire.
 No, they are not hidden in core or on disk at
 the intermediate and final message transport
 nodes. That's bad.

 There is no way to hide metadata because you need a destination for your 
 messages to arrive ... has to find its destinations to deliver its contents.

I generally meant TLS hides the multitude of headers, but
headers themselves are not today encrypted to the recipient
or to the network, so they end up sitting in the open... and
their SMTP style and purpose totally unnecessary to a new
transport network.

Yes of course... the minimum necessary for delivery is the
destination address. If the network design ends up yielding
control protocol returned from the network to the sender, the
source must be present. Your network client node handles
decrypting the content to find enclosed within (or to configurably
affix if missing) any further traditional headers if needed by your
local messaging agent, routing stack, etc. Such content may
contain the unique address key of your correspondant, be signed
by them, etc.

Dest: unique destination address key
Optional network metadata: ...
Src: optional unique src address key if control feedback
Content: encrypted blob

'Optional network metadata' may be needed depending on
the network design, full of sigs, routing, storage or other data.
But it most certainly won't be SMTP headers as we know them
today. And will be encrypted to shield from all but the most
minimum of nodes possible.

Further, if the network ends up being general purpose
bidirectional, such that you might run IP traffic/apps over it,
the source address key will obviously be required in
either the Src or Content contexts.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Thu, May 15, 2014 at 8:36 AM,  tpb-cry...@laposte.net wrote:
  - Email is entrenched in the offices, many a business is powered by it;

 They are powered by authorized access to and useful end use of message
 content, not by email. That's not going anywhere, only the intermediate
 transport is being redesigned.

 Can you recode outlook, eudora and other closed source stuff people use(d) 
 for e-mail handling for business? No? Well, that answers why it is hard to 
 remove.
 Fixing the problem is better than overhauling all offices in the world,

Nobody can recode closed source but them. I would offer [pluggable]
open source alternatives and let gravity move the closed ones
over time.

  Given the enormous energy necessary to remove such an appliance and 
  replace

 Removal is different from introducing competitive alternatives.

 Little proprietary walled gardens are absolutely not the answer for this 
 problem.

Nothing proprietary being made here, all open source, hack and use freely.

  it with something better. How could we make a secure solution that plays
  nicely with the current tools without disturbing too much what is already
  established?
 
  By writing a gateway (i.e. between RetroShare and e-mail)?

 The gateway idea is interesting, but it has to be efficient enough and low 
 cost enough for people to switch over. Something like bitmessage is not.

 MUA's become file readers and composers. They hand off
 to a localhost daemon that recognizes different address formats
 of the network[s] and does the right thing. Perhaps they compile
 against additional necessary network/crypto libs. Whatever it
 is, those are not a big change. Ditching centralized SMTP transport
 in the clear is... and for the better.

 http://arstechnica.com/security/2014/05/good-news-for-privacy-fewer-servers-sending-e-mail-naked-facebook-finds/
 I think that answers your concern about SMTP transport in the clear

Yes, great, we're now moving towards strict and PFS encrypted transport.
That's not much of a complete achievement since it does not solve any of
the other snowden-ish issues recent p2p threads are meant to encompass...
- [secret/trollish/illegal] orders against centralized mail servers/services
to store and disclose all metadata and [unencrypted] content, including
transport headers and pesky to/from/subject/etc headers.
- voluntary 'cooperation' to do the same.
- capability for messaging over encrypted anonymous p2p overlay networks
so that the only real place left to compel is the investigated user themselves
(or millions of users if you want to fight up against free speech / privacy).

 you clearly haven't been in may offices in your life.

Don't say on others position until you are their shadow.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

 pesky to/from/subject/etc headers.

 Oh boy, here we go.
 Those are hidden by use of TLS.

Have you not been following the weaknesses intrinsic
to SMTP discussions?
Yes, they are hidden in TLS transport on the wire.
No, they are not hidden in core or on disk at
the intermediate and final message transport
nodes. That's bad.

We want all human relevant plaintext content, such pesky
headers included, to be hidden from observation by anyone
other than us (at our origination or final receipt nodes).
There is no oh boy in that sensible new design.

 Regarding government wanting your data in the clear by requesting it to the 
 ISP you use, well switch your communications to another country, problem 
 solved.

Have you ever heard of MLAT, extradition, interpol, public
and private cooperation, dealings, and other such things? And
maybe you simply do not trust any 'country' with carriage of your
insistent plaintext. There is no such 'solved' with that.

 - voluntary 'cooperation' to do the same.
 - capability for messaging over encrypted anonymous p2p overlay networks
 so that the only real place left to compel is the investigated user 
 themselves
 (or millions of users if you want to fight up against free speech / privacy).


 p2p is no panacea, it doesn't scale

I believe it could. Even if requiring super aggregating
nodes of some sort. Layers of service of the whole
DHT space. More research is surely required.

 and it will never, ever be able to handle the latest netflixy app Joes are so 
 much into.
 p2p is for techead kids like you, not for the masses.

We are talking messaging, not bulk data.
However, once you have the nodes scalable to millions
of communicators, there is probably no issue transporting
bulk data among a select few along their path metrics.

Cathal brings up a great and tricky issue regarding
choices to store-and-forward. SF is quite more
complex, but possibly more useful, than realtime.

 The masses do not understand it unless it brings spiderman, batman, faggotman 
 hollywood garbage faster to their living rooms.

I agree such garbage is rather pointless life endeavour.
I would be happy to message you via such a new
messaging system though :)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Fri, May 9, 2014 at 11:49 AM, rysiek rys...@hackerspace.pl wrote:
 Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-cry...@laposte.net pisze:
 Although technical solutions are feasible

Then do it and see what happens.

 we ought to consider some things:
 - Email is older than the web itself;

So is TCP/IP and the transistor. Irrelevant.

 - Email has three times as many users as all social networks combined;

And how did those nets get any users when 'email' was
supposedly working just fine?

 - Email is entrenched in the offices, many a business is powered by it;

They are powered by authorized access to and useful end use of message
content, not by email. That's not going anywhere, only the intermediate
transport is being redesigned.

 Given the enormous energy necessary to remove such an appliance and replace

Removal is different from introducing competitive alternatives.

 it with something better. How could we make a secure solution that plays
 nicely with the current tools without disturbing too much what is already
 established?

 By writing a gateway (i.e. between RetroShare and e-mail)?

MUA's become file readers and composers. They hand off
to a localhost daemon that recognizes different address formats
of the network[s] and does the right thing. Perhaps they compile
against additional necessary network/crypto libs. Whatever it
is, those are not a big change. Ditching centralized SMTP transport
in the clear is... and for the better.

Reread the threads, forget about that old SMTP box, think new.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] OT: Speeding up and strengthening HTTPS connections for Chrome on Android

[grarpamp]

On Fri, Apr 25, 2014 at 5:36 PM, ianG i...@iang.org wrote:
 On 25/04/2014 22:14 pm, Jeffrey Walton wrote:
 Somewhat off-topic, but Google took ChaCha20/Poly1305 live.
 http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html

 ... It also *does not support any cipher suite negotiation*,
 instead it always uses a fixed suite (the current
 implementation[2] uses ECDHE-Curve25519-Chacha-Poly1305).

Where is this last bit quoted from? The full suite as (pictured) in
the blog is: ecdhe_rsa_chacha20_poly1305.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [tor-talk] The Heartbleed Bug is a serious vulnerability in OpenSSL

[grarpamp]

On Tue, Apr 8, 2014 at 2:02 PM, Joe Btfsplk joebtfs...@gmx.com wrote:
 On 4/7/2014 6:14 PM, grarpamp wrote:
 http://heartbleed.com/
 Patch your stuff.

 Comments / suggestions from those w/ in depth knowledge in this area?  How
 users should proceed; how to check if sites used (banks, email, retail
 sites, etc.) were / still are affected, so one knows if  when to change
 passwords or other data?

 If the number of sites potentially affected is as large as indicated on
 heartbleed.com, changing PW on even 60% of sites I use could take a long
 time - even to do it once.

 It would do little good to change a password on a site that hasn't patched
 this.
 Or perhaps it would do some good, to change the password before logging out
 of a site?  Then when a site must be accessed again, change the password
 again.

 Either way, this might not provide perfect safety, but might ? be better
 than nothing.

https://blog.torproject.org/ covers what to do for Tor things.

For everything else on the net, fix the clients and servers you're
responsible for. Then...

You're right, there's a big gotcha in all this, users won't really know if
the services they interact with have been fixed [1] because huge swaths
of services simply don't publish what they do on their pages, they bury
it to keep quiet and shiny happy sites. Only some banks, insurers, utilities,
schools, etc will post we're fixed anywhere remotely prominent. So
you have to trust they did [2], which is a reasonable assumption given
regulation and liability of big institutional services. You should already have
a regular password changing/logout/session management regimen, so
inserting some extra instances of that along guesstimates of [2] should
suffice with these classes of service.
[2] Sometime during the falloff curve starting yesterday afternoon.

The real user risk is likely on mid to small services, embedded things, shared
platforms, legacy systems, services that didn't get the news, don't have
the resources or knowledge to fix, etc. Again, consider some form of
reasonable regimen.

And there are all sorts of tools and site testing services coming out
now for which a brave user might be completely warranted in using to
determine [1 above] so they know when to utilize [regimen 2].
(Far better to use a testing service or email their help desks seeking
a positive statement than risk being potentially considered an exploiter
of things you don't own.)

Partial list...

http://s3.jspenguin.org/ssltest.py
https://gist.github.com/takeshixx/10107280
https://github.com/FiloSottile/Heartbleed
https://www.ssllabs.com/ssltest/index.html
(Note, this is a TLS in process bug, so more than HTTP/S services are
affected...)

This bug will no doubt trigger some thinking, analysis and change in
the services,
security, infrastructure and user communites... that's a good thing.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] 2010 TAO QUANTUMINSERT trial against 300 (hard) targets

[grarpamp]

On Thu, Mar 13, 2014 at 11:13 AM, Jason Iannone jason.iann...@gmail.com wrote:
 And remain undetected?  That's a nontrivial task and one that I would
 suspect generates interesting CPU or other resource utilization anomalies.
 It's a pretty high risk activity.  The best we can hope for is someone
 discovering the exploit and publicly dissecting it.

See, the standard defense for all this is to lock down the cert fingerprints of
your real destination to prevent cert games. Then add in DNSSEC [1] and even
IPSEC [1] to make sure things all match up. That does make things much harder.
Problem still lies where your adversary has stolen or co-op'd the PK
of your dest
cert, and rigged the routing path to route-map your applicable src/dest/port IP
tuples to residing off their private port in the local (to you or your
dest) DC. Right???
From which they proceed to bugger you through their transparent proxy
to the real
dest. It's not a bulk tool as that might tip off some non-moled-out-cert-group
network groupie at the dest site that a lot of users come from some IP. And it's
definitely for 'high value only' given the work/risk. But still...
PKI-WOT bidirectional
security between you and your dest of global bgp advert/nexthop routing
infrastructure anyone? Everyone seems to trust the network to route... and
even then [1].
[1] Similarly stolen/co-op'd as need be.


 pg
 This is relatively easy for home routers, since the self-signed certs they're
 configured with are frequently CA certs.  In other words they ship from the
 factory in a MITM-ready state.


 On Thu, Mar 13, 2014 at 8:50 AM, Greg Rose g...@seer-grog.net wrote:

 You get the routers to create valid-looking certificates for the
 endpoints, to mount man-in-the-middle attacks.

 On Mar 13, 2014, at 6:28 , Jason Iannone jason.iann...@gmail.com wrote:

  The First Look article is light on details so I don't know how one gets
  from infect[ing] large-scale network routers to perform[ing]
  “exploitation attacks” against data that is sent through a Virtual Private
  Network.  I'd like to better understand that.
 
 
  On Thu, Mar 13, 2014 at 7:22 AM, Jeffrey Walton noloa...@gmail.com
  wrote:
  On Thu, Mar 13, 2014 at 9:17 AM, Jason Iannone jason.iann...@gmail.com
  wrote:
   Are there details regarding Hammerstein?  Are they actually breaking
   routers?
  Cisco makes regular appearances on Bugtraq an Full Disclosure. Pound
  for pound, there's probably more exploits for Cisco gear than Linux
  and Windows combined.
 
  Jeff
 
   On Thu, Mar 13, 2014 at 2:40 AM, Jeffrey Walton noloa...@gmail.com
   wrote:
  
   On Thu, Mar 13, 2014 at 1:57 AM, coderman coder...@gmail.com wrote:
   
   
https://s3.amazonaws.com/s3.documentcloud.org/documents/1076891/there-is-more-than-one-way-to-quantum.pdf
   
TAO implants were deployed via QUANTUMINSERT to targets that were
un-exploitable by _any_ other means.
   
   And Schneier's Guardian article on the Quantum and FoxAcid systems:
  
  
   http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Commercialized Attack Hardware on SmartPhones

[grarpamp]

The liberationtech list occaisionally has threads on this.
Then things like guardianproject are working on hardening and
even making alternate phone OS's. ie: I think there may
now be some porting of some BSD's to phone cpu's, not that
it is much different from linux/droid in regard.
Then remember a paper about phone's baseband processors
being able to, iirc, access phone's ram out of band...
So now some people are talking about making open phone hw.

I've yet to read jakes good links but i suspect by titles they
may confirm some thoughts that phones are not real secure
platforms yet. This may not change until the outcry/liability risk
from eating customers personal privacy/financial losses exceeds
the corp benefit (pick some) from continuing to make accessible
phones.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] MaidSafe: p2p encrypted anonymous drivesharing homedir network?

[grarpamp]

On Tue, Jan 28, 2014 at 10:03 AM, Kevin kevinsisco61...@gmail.com wrote:
 What sort of claims?

1) secure
2) anonymous
3) free
4) the usual etc
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] MaidSafe: p2p encrypted anonymous drivesharing homedir network?

[grarpamp]

Lots of unknown popups making bold claims lately
that should be looked into... discuss?


-- Forwarded message --
From: David Irvine david.irv...@maidsafe.net
Date: Sun, Jan 26, 2014 at 10:51 AM
Subject: [bitcoin-list] Meeting place to discuss 'the decentralised
internet' projects
To: bitcoin-l...@lists.sourceforge.net


Hi sorry for barging in, but with all of the projects now based around
decentralisation, I thought a common place to exchange ideas would be good.
I have created a subreddit
http://www.reddit.com/r/decentralisedinternet as a place for as many
projects to collaborate and share experiences,
research and general comments.

I am hoping to make this an open environment for discussion and technical
debate, but not a place of project wars. This is essential and to that end
I would like to engage with you and have you all sign up to the subreddit.
I believe as we recodnise more projects then at least one person from each
project should be a moderator. This should add stability and ensure that
each project is protected as they all have their own path to follow. I
suggest each project puts forward an admin and I will add them immediately.
I believe there is enough of a push now to decentralise services and
working together to achieve all of our goals can only be a good thing.

Below is the sidebar text as it stands, this is all open for debate.

This is a reddit of logic and not emotion, please base all debate on logic.
We do not want project wars here, so no vim/emacs type debate between
projects. Keep focussed and logical if at all possible.

Whilst people will prefer one project over another, the point of this
subreddit is to find the technically best solutions to the miriad of issues
and share technology and discussion between projects. Advertising is not a
goal of this subreddit, although new information about projects is
encouraged.

Submissions that are mostly about some other server based solutions belong
elsewhere.

Please avoid repetition — /r/decentralisedinternet is a subreddit devoted
to new information and discussion about decentralisation of the Internet.
New projects are welcome to announce themselves via this reddit, but after
those have been announced they are no longer news and should not be
re-posted. New news will be accepted. Aside from new project announcements,
those interested in advertising to our audience should consider Reddit's
self-serve advertising system.

Projects so far (please request to be added by posting a link to your
project, if it is upvoted and agreed by redditors to be accepted it will be
added here)

Freenet
Tahoe
bitcoin
MaidSafe
bitcloud
twister
##
I am sending this message to each of the projects mentioned and any others
that should be included as we progress.


--

David Irvine
maidsafe.net http://www.maidsafe.net/
twitter: @metaquestions
blog:  http://metaquestions.me
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
bitcoin-list mailing list
bitcoin-l...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Fwd: Email is unsecurable - maybe not?

[grarpamp]

More direct junkmail...

-- Forwarded message --
From: Doug McFetters dmcfett...@shazzle.com
Date: Thu, Jan 16, 2014 at 2:06 PM
Subject: Email is unsecurable - maybe not?
To: grarp...@gmail.com


Hello



I ran across the Nov 25 blog post on RandomBit.net titled ‘Email is
unsecurable.’



I think we have pretty much developed what was imagined here.  We
identified the same flaws with email and came up with sending p2p tossing
aside client/server architecture and using the sender’s smartphone as a
server.  And, like it was suggested, we don't send until someone comes up
on line.



App is free for consumers with iOS or Android device.  Currently have tools
for POP3/SMTP clients or our own slimmed down email client.



Would love for you to try it out and let us know what you think.  Or happy
to hop on a call to discuss in more detail.



Here is a link to get started - http://shazzlemail.com/quick-start



Thanks



Doug









Doug McFetters

VP, Operations

Public: dmcfett...@shazzle.com

Private  Secure: d...@zmail.shazzlemail.com

(602) 793-1058



[image: Logo v7 small]

ShazzleMail.com http://www.sparqd.com/ | Visit us on Facebook!



This email is only for the use of the intended recipient.  Any unauthorized
use or distribution is prohibited.  If you received this email in error,
please reply to the sender and destroy all copies of the email.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] using Curve p25519 cryptography for type 2(Mixmaster) and type 3(mixminion) remailer blocks

[grarpamp]

 On Tue, Jan 14, 2014 at 2:14 PM, gwen hastings g...@cypherpunks.to wrote:
 ...
 I am looking at resurrecting

 mixmaster, mixminion and nym.alias.net nymserver designs from the
 various code wastebaskets and retrofit them with some newer encryption
 technology based on curve25519 and poly-1305 libsodium based algorithms
 and routines.

I believe there is sufficient demand to merit deployment of a
good mix network. As well as perhaps web/other intake frontends
due to the now prevalent a) dwindling free email b) demand by
mail providers for phone authentication. As for operators, I'd
reach out to the Tor, I2P, Bitcoin, etc operators.
It's a shame that one of the hardest things to find these days is
anonymous free speech in the simple form of the written word.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Tue, Dec 24, 2013 at 5:09 AM, danimoth danim...@cryptolab.net wrote:
 On 24/12/13 at 04:20am, grarpamp wrote:
 This thread pertains specifically to the use of P2P/DHT models
 to replace traditional email as we know it today. There was
 a former similarly named thread on this that diverged... from the
 concept and challenge of P2P/DHT handling the transport and
 lookups... back to more traditional models. This thread does not
 care about those antique models, please do not take it there.

 A problem which could rise is the 'incentive' for peers to continuosly
 providing bandwidth and disk space to store messages. I'm a simple dude,
 with a mailflow of ~5 email per day. Why I should work for you, with
 your ~1 mail per day for all your mailing list?

 Somewhere on this list (or p2p-hackers?) there was a post of mine,
 regardings an economic incentive between peers, which could be a
 solution, but as always technical problems arose, like pricing the
 services and a fair exchange between peers.

There may be advantage to the security of your own traffic if you
also handle the traffic of others.

Economically, it's probably not right to expect 'free' transport in
such a system. Though perhaps at minimum you should be
expected to provide benefit to the network an equivalent of what you
consume, including the extended cost to the net of your consumption.
ie: in a multi-hop network your impact is not just over your own interface.

And in an anonymous network it's most assuredly not right to
force users to pay using non-anonymous payment methods.
Though they may optionally do so if they wish.

How close is the research on these issues to being codeable
into actual p2p transports (whether anonymous (preferred) or not)?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] The next gen P2P secure email solution

[grarpamp]

On Wed, Dec 25, 2013 at 8:21 AM, Jeremie Miller
jeremie.mil...@gmail.com wrote:
 This thread seems pretty immense and in various places, what's the best way 
 to contribute to it?

 I'm pretty keen on the topic, been working on /real/ p2p infrastructure for 
 5+ years now :)


I'm not sure that it has a proper home. I do not suggest metzdowd,
which is where I think you picked it up. cypherpunks has the most
thread content to date. Though p2p-hackers is perhaps best for now
unless anyone else has a better idea? ie: another p2p centric list
with a good bit of anonymity and crypto representation.
p2p-hackers is having delivery issues at the moment so maybe
continue to cc cypherpunks for another week till that is sorted out.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Wed, Dec 25, 2013 at 7:19 AM, Randolph rdohm...@gmail.com wrote:
 Anyone looked at BitMail p2p ?
 http://sourceforge.net/projects/bitmail/?source=directory

re: bitmail, goldbug, etc.

With all due respect, I doubt few here have or will anytime soon.
You spam out links to binaries no one's heard of, your source probably
isn't deterministic to your binaries, bsd/linux support?, your development
model doesn't appear open, code is hosted on a site few care about anymore,
you've no papers, presentations, mailing list or community involvement,
you've advertised the good name of other projects as being affiliated with
your work without their permission. And you've failed to address any of
this publicly despite people kindly prompting you to do so. In these
communities, that's a big red flag.
As always, full benefit of the doubt is given. If you need hosting for code,
lists, website... some code review, testing, etc... just ask an appropriate
list. We need more cool ideas and software... but you really need to step
up to the plate in these areas if you want people to take you seriously.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] The next gen P2P secure email solution

[grarpamp]

This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today. There was
a former similarly named thread on this that diverged... from the
concept and challenge of P2P/DHT handling the transport and
lookups... back to more traditional models. This thread does not
care about those antique models, please do not take it there.

In short, we're attempting to examine and develop some form
of new transport that looks somewhat like a mix between secure
anonymous networks, string@pubkey node addressing, massive
decentralized dht-like scaling and finally a user facing daemon that
moves messages into and out of local spools for use by normal
user/system tools.

Pasting in a very rough and unflowing thread summary to date
for interested people to pick up and discuss, draft, etc.

=
grarpamp...
 [pgp/smime email encryption, etc]
 What is the gap we have to close to turn this on by default?

How many times has this been rehashed the last six months?
You can't fix email as we know it today using todays bolt-ons,
protocols and corporate stakeholders/services trying to profit from it.
The only way to have any real global seamless success is to go
ground up with a completely new model. IMO, that will be some
form of p2p message system where every address is a crypto key,
masked for grandma by her contact list, decrypted out your p2p
daemon and piped into your local mail processing (MUA/filter/lists)
and filesystem (encryption). At least that way your local mail tools
will still work (no one will give those up anyway).

The problem is the antique centralized backend, it needs bypassed.
You've got neat stuff like Tor, bittorrent, bitcoin, etc already... so
boost email into the 2020's the same way. Then let the old world
email services try to keep up, and slowly die like everything else.
=
grarpamp...
On Mon, Nov 25, 2013 at 1:01 AM, ianG i...@iang.org wrote:
 On 23/11/13 15:30 PM, Ralf Senderek wrote:
 On Sat, 23 Nov 2013, David Mercer wrote:

 But of course you're right about actual current usage, encrypted email
 is an
 epic fail on that measure regardless of format/protocol.

 Yes, but it's about time we do something about that. Do we *exactly know
 why* it is such a failure?

 It's an interesting question, and one worth studying for pedagogical
 motives.  From my experiences from both sides, it is clear that both sides
 failed.  But for different reasons.
 Hence, I've concluded that email is unsecurable.

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

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

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

Anyway, p2p messaging and anonymous transports have
all been dreamed up by others before. But now is the
time to actually abandon traditional email and just do it.
If you build it, they will come.
=
fabio...
I'm strongly against most the ideas to abbandon current email systems,
because the results will be to create wallet garden.

We need something interoperable with existing systems or the system will
just be used by a bunch of paranoid people or fostered by the marketing
of few cryptography company acquiring customers, not user.
=
grarpamp...
It would be interoperable with current end user interfaces/tools, but not
directly with you@some.dotcom.
As with everything else, today's seeds grow into tomorrows garden, sometimes
you just have to thorougly plow under last year's chaff first, that's by design.
=
viktor...
E-mail is basically business correspondence.

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

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

[grarpamp]

More summary pasting...

/ Someone...
/ There are people I know who do not mind the extra steps for pgp. I
/ certainly want to get the roll out to use and test and enjoy. Sign me
/ up.

grarpamp...
Encryption is only part of it. There's transport, elimination of
central storage, anonymity, p2p, etc. Many things people want
simply can't be done with modifications to the current system.
With p2p model and every node as a key/address, you don't
need 'pgp' because the node is the key and does lookups and
encrypt2dest / decrypt2you for you. But you can still use pgp with
the usual tools around message bodies if desired for additional
encrypt/auth or if you're disk isn't encrypted. P2P daemon
takes over and all the old transport headers go away.
Spam/AV becomes another local daemon. Mailing lists are
a repeater node someone runs, or the usual local mailman stuff.
It's a transport replacement, so business can use it account@node.
All the MTA's [connected directly to the internet] die off in time.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Tue, Dec 24, 2013 at 5:09 AM, danimoth danim...@cryptolab.net wrote:
 A problem which could rise is the 'incentive' for peers to continuosly
 providing bandwidth and disk space to store messages. I'm a simple dude,
 with a mailflow of ~5 email per day. Why I should work for you, with
 your ~1 mail per day for all your mailing list?

I think this is one of many design choices to be made.

Extra bandwidth is hard to avoid, unless the topology is
point(sender)-to-point(recipient). Yet with that, there is no effort made
to hide who is physically talking to who. We want to try to defeat this
type of analysis, so we can't be simply point-to-point.
 ie: bittorrent and today's email are point-to-point, no multihop.

Next is storage (mix) vs. latency (tunnels). This seems less clear to
me when up against analysis. Filling circuits (tunnels) with chaff
seems interesting. And with deliverey directly to your recipient over
some tunnel circuit, you don't have to build in complex message redundancy
protocols (more storage float outstanding) to ensure your message 100%
gets there when 90% of the nodes go offline taking your stored message
with them. You also get direct realtime delivery confirmation too.

 Somewhere on this list (or p2p-hackers?) there was a post of mine,
 regardings an economic incentive between peers, which could be a
 solution, but as always technical problems arose, like pricing the
 services and a fair exchange between peers.

The question arises, how does one provide free anonymous transport
to those anons who simply can't pay because they are anon? How
do you 'get users' when the mentality is 'for free'? Bittorrent/Tor are
free and seem to work ok. Though it's also probably not unreasonable
to suggest (and harder to enforce) that you get 1:1 what resources you
donate to it. ie: I need to push 1GiB this month, so I need to provision at
minimum 1+Nx1GiB to do that... 1 for me, Nx1 for the net due to my use
(where N is some impact ratio inherent in the design of the net, such
as number hops.)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Tue, Dec 24, 2013 at 5:03 AM, Natanael natanae...@gmail.com wrote:
 Somebody in there mentioned allowing IPv6 addressing on top of I2P/Tor. That
 would be Garlicat/Onioncat. It creates a local virtual IPv6 network
 interface for your software to use, so that you can map key based addresses
 to routable local addresses.

 https://www.onioncat.org/about-onioncat/

It is worth noting that Phantom does this natively without needing an overlay on
top of another net. It may also use disk to cache some network information, at
least their whitepaper says they are 'for' making that choice. Perhaps it can be
scaled? https://code.google.com/p/phantom
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

On Tue, Dec 24, 2013 at 5:01 AM, danimoth danim...@cryptolab.net wrote:
 In these months there was a lot of talking about metadata, which SMTP
 exposes regardless of encryption or authentication. In the design of
 this p2p system, should metadata's problem kept in consideration or not?
 IMHO exposing danimoth@cryptolab or my key it's the same, as there is
 a function between them. I2P and/or Tor adds complexity to avoid such
 mapping to any non-state-level adversary.

I'd assume the design will rightly provide complete end2end encryption between
your source spool and your recipients spool over whatever bits are in between,
as a result of having the key, equivalent to the node, equivalent to
the address.
Store and forward might need to expose only the destination key to the storage
and routing net. A direct circuit would not.

All the legacy 'received' headers are gone by definition. A full raw message
might contain some required bits for continued use with your favorite mail tools
post handoff to you:

From - As with today, this may or may not end up being authenticateable by the
recipient. Since the net itself would seem to need to be anonymous, then it is
likely not. Nor is it a problem if it is... you just generate yourself
a new node if concerned.
To, Cc, Bcc
Date
Subject
Message-ID
[Threading]
Body

Antispam/antivirus becomes responsibility of the sender/recipient so no
headers there. No legacy dkim, spf, etc, either.

There may be a new set of transport preference headers if the design calls
for it. ie: You might be able to use the net with full mail clients
like mutt, thunderbird.
Or with a light 'messaging' client protocol. Each of which might have
a slightly different
interface into and out of the node.

Addresses might look like:
[user/function or protocol/arbitrary string]@[node pubkey/hash]

I've no idea, only to see if interested people think some sort of nextgen
P2P/DHT system is actually possible at scale.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Gaps in email [was: PGP userbase]

[grarpamp]

 Phillip H-B, et al have been saying...
 [email encryption, etc]
 What is the gap we have to close to turn this on by default?

 How many times has this been rehashed the last six months?
 You can't fix email as we know it today using todays bolt-ons,
 protocols and corporate stakeholders/services trying to profit from it.
 The only way to have any real global seamless success is to go
 ground up with a completely new model. IMO, that will be some
 form of p2p message system where every address is a crypto key,
 masked for grandma by her contact list, decrypted out your p2p
 daemon and piped into your local mail processing (MUA/filter/lists)
 and filesystem (encryption). At least that way your local mail tools
 will still work (no one will give those up anyway).

 The problem is the antique centralized backend, it needs bypassed.
 You've got neat stuff like Tor, bittorrent, bitcoin, etc already... so
 boost email into the 2020's the same way. Then let the old world
 email services try to keep up, and slowly die like everything else.


/ There are people I know who do not mind the extra steps for pgp. I
/ certainly want to get the roll out to use and test and enjoy. Sign me
/ up.


Encryption is only part of it. There's transport, elimination of
central storage, anonymity, p2p, etc. Many things people want
simply can't be done with modifications to the current system.
With p2p model and every node as a key/address, you don't
need 'pgp' because the node is the key and does lookups and
encrypt2dest / decrypt2you for you. But you can still use pgp with
the usual tools around message bodies if desired for additional
encrypt/auth or if you're disk isn't encrypted. P2P daemon
takes over and all the old transport headers go away.
Spam/AV becomes another local daemon. Mailing lists are
a repeater node someone runs, or the usual local mailman stuff.
It's a transport replacement, so business can use it account@node.
All the MTA's die off in time.

[Please direct list replies to the list, not me. I should have broke
the subject earlier.]
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The next generation secure email solution

[grarpamp]

Moving the last couple days talk to this thread seems fine.

On Sun, Dec 15, 2013 at 3:19 PM, Ralf Senderek cry...@senderek.ie wrote:
 On Sun, 15 Dec 2013 grarpamp wrote:

 The only way to have any real global seamless success is to go
 ground up with a completely new model. IMO, that will be some
 form of p2p message system where every address is a crypto key,
 masked for grandma by her contact list, decrypted out your p2p
 daemon and piped into your local mail processing (MUA/filter/lists)
 and filesystem (encryption). At least that way your local mail tools
 will still work (no one will give those up anyway).


 If you are so sure, can you tell us how the next generation secure email
 solution will solve the trust problem, please.

Though unclear, that sounds like the old trust of a CA/PKI system problem.

 How does the p2p daemon
 find the correct crypto key, so that every user can rely on its invisible
 performance?

In general I suggest that people wish to use messaging with each other
once they already know them (or have some other trusted web to them).
As in, Hey John, nice to meet ya today, what's your key (address), I'll
message you later. Or Hey Jane, what's John's address. Same for
employers, businesses, etc. Such peer groups bootstrap and grow
very fast. Thus the perceived need for a cold lookup of Ralf, isn't much of
a real one.
Once you know the address (node crypto key), you put it 'To: key',
mua hands to spool, p2p daemon reads spool, looks up key in DHT and
sends msg off across the transport to the far key (node) when it is
reachable. Hopefully the transport looks like I2P/Tor in being a secure
random hop layer. In fact, those could probably be used today, they
have the keys as nodes and user facing ports for inbound/outbound
daemons. They just need scaling work to n-billion nodes (users,
aka: the hard part). People are already plugging postfix, bittorrent,
etc into these networks.

Tor is not currently addressible at the user level by the full key,
it 'shortens' the key into a 16char onion address. As you may be
hinting at... yes, that is bad... collisions, and needing secondary lookup
layers into the full key. Tor may be moving to full key addressibility
soon, see tor-dev for that.

I2P (and Phantom, and probably GnuNet) are addressible with full keys.
So you can send to 'account@key' with them if you want, and keep the
John/Jane/Ralf human style lookups in your MUA addressbook (once
you know them) without needing a secondary lookup layer into the full key.

No, I am not sure. But when looking at some of the p2p transport
layers that have come along so far, it seems like a fairly strong
possibility for a new backend transport model while retaining user
level mail tools... mutt, maildrop, mailman, Thunderbird, etc. Most
of what you'd need there is support for very long addresses and
split horizon handoff to local daemon/spool based on recognizing
what the destination net is... .onion, .i2p, etc.
I'd like to read what Pond and I2P-Bote are doing with some parts of
this as well.

I don't believe you need a trusted CA/PKI service to successfully
bootstrap users and their addresses/keys into a new global messaging
system. If I want to know what some unknown like Bruce's key is, I'll
look it up on his website, social net, list posts, etc. If that's what you
mean.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[grarpamp]

On Mon, Nov 25, 2013 at 1:01 AM, ianG i...@iang.org wrote:
 On 23/11/13 15:30 PM, Ralf Senderek wrote:
 On Sat, 23 Nov 2013, David Mercer wrote:

 But of course you're right about actual current usage, encrypted email
 is an
 epic fail on that measure regardless of format/protocol.

 Yes, but it's about time we do something about that. Do we *exactly know
 why* it is such a failure?

 It's an interesting question, and one worth studying for pedagogical
 motives.  From my experiences from both sides, it is clear that both sides
 failed.  But for different reasons.
 Hence, I've concluded that email is unsecurable.

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

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

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

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

Re: [cryptography] Fwd: GB Secure Messenger V 06 released

[grarpamp]

On Thu, Oct 24, 2013 at 5:50 PM, R.R. D. rdohm...@gmail.com wrote:
 fwd fyi
 -- Forwarded message --
 Subject: GoldBug Secure Messenger V 06 released
 http://goldbug.sf.net

Forwarded eh? From who, or where? ... 'mikeweber', 'berndhs'?
Public mailing list, forum, website, bugtracker, IRC?
You keep spamming this software at us and never have anything
to actually *say*. Care to meet up at a con, give a little presentation,
sign some keys? Have any design whitepapers for the libraries?
I can respect the silent anon developer thing (hi satoshi ;), but it doesn't
work for a *lot* of people. Are you asking for a design or code review?
Some testing/UI feedback? Help us out here, what's the deal?
I'm sure folks would help. But as other's have said, lots of questions,
few answers.

Also, please quit sending me invites to things.
Cute puppy and nice echo music video though (complete with
SeaLand imagery).

But hey, if it attracts more people who end up watching this
video as linked from your site, it's all good.
https://www.youtube.com/watch?v=0U37hl0n9mY
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] FreeBSD crypto and security meta

[grarpamp]

 https://lists.freebsd.org/pipermail/freebsd-security/2013-October/007226.html

http://www.freebsd.org/news/status/report-2013-07-2013-09.html#AES-NI-Improvements-for-GELI
http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Reworking-random(4)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] FreeBSD crypto and security meta [was: zfs review 4185 New hash algo]

[grarpamp]

 Date: Mon, 7 Oct 2013 11:44:57 +0200
 From: Pawel Jakub Dawidek p...@freebsd.org
 To: z...@lists.illumos.org
 Subject: Re: [zfs] [Review] 4185 New hash algorithm support

 On Mon, Oct 07, 2013 at 12:47:52AM +0100, Saso Kiselkov wrote:
 Please review what frankly has become a bit of a large-ish feature:
 http://cr.illumos.org/~webrev/skiselkov/new_hashes/

 This webrev implements new hash algorithms for ZFS with much improved
 performance. There are three algorithms included:
 [...]

 Personally I'd love to have an option to use HMAC/SHA256 for example
 with secret key stored in pool. Currently in our product we put ZFS with
 SHA256 on top of block-level disk encryption. I'd feel much better to
 have proper data authentication using HMAC. At some point I may find
 time to implement that based on your patch.

With recent news renewing broad interest in self/peer examining
the security of the entire spectrum of products... has the FreeBSD
implementation of GELI/crypto/random published design papers,
presentations and reviews? Are these collected centrally for easy
reference by the community?

Quick ref:
https://www.freebsd.org/cgi/man.cgi?query=geli
https://www.freebsd.org/cgi/man.cgi?query=cryptosektion=9
https://www.freebsd.org/cgi/man.cgi?query=cryptosektion=4
https://www.freebsd.org/cgi/man.cgi?query=randomsektion=4
https://www.freebsd.org/cgi/man.cgi?query=rndtestsektion=4

Further, and more generally on the higher level meta topics we've seen...
How is FreeBSD working with the community regarding possible
updates to cipher suites, embedded crypto libraries, and the like?
Similarly, how is it approaching the movement towards end-to-end
toolchain integrity... from the repository, through deterministic builds,
and on out to secure distribution and updates?

This should be viewed not as a pointer but 'While we're on the topic,
hey, how are the FreeBSD folks doing' :) Presumably this subthread
could migrate to freebsd lists for those interested in following the
details more closely.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Daniel the King. Jon the President. Linus the God?

[grarpamp]

On Sat, Oct 5, 2013 at 4:21 AM, ianG i...@iang.org wrote:
 Long Live Competition!

There should be no King to serve, no Committee to subvert, only an open Process.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [tor-talk] Guardian Tor article

[grarpamp]

Some have said...

 this [Snowden meta arena] has been a subject of discussion on
 the [various] lists as well

 Congrats, torproject :-D

 Tor Stinks means you're doing it right; good job Tor devs :)

 good news everybody; defense in depth is effective and practical!

Yes, fine work all hands, everyone have a round at their favorite
pub/equivalent tonight.


 Of course, this is also from 2007. It's been a long time since then.

Yet whether from 2007 or last week... when Monday rolls around, we
must channel all this joy and get back to work. For the risks and
attackers that we all face are real, motivated, well funded, and
do not play fair by any set of rules. They do not stop and neither
can we. Wins that do not result in elimination from the game are
but temporary gains. We must always be better... train, practice,
discipline, and enter ourselves into every race... leaving only a
continuous cloud of dust behind for our adversaries to choke on.

Till Monday, I got this round :)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[grarpamp]

On 9/27/13, Eugen Leitl eu...@leitl.org wrote:
 I don't see how a ham running a repeater backbone can
 prevent end to end encryption other than sniffing for
 traffic and actively disrupting it. I'm not sure tampering
 with transport is within ham ethics, though they definitely
 don't understand the actual uses for encryption, at
 least the old hands (are there even new hands?).

The mentioned tech has nothing to do with traditional 'ham'.
And without the crypto key they can't see it and can't disrupt
it, it's background/spectrum noise/power to them.
Traditionally, presumably hams might discover non-in-the-clear
on a specific channel, perhaps triangulate, and report it to some
regulatory body (or DoS it). That's not applicable, by design.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[grarpamp]

On 9/27/13, Eugen Leitl eu...@leitl.org wrote:
 On Fri, Sep 27, 2013 at 01:12:19PM -0400, grarpamp wrote:

 The mentioned tech has nothing to do with traditional 'ham'.
 And without the crypto key they can't see it and can't disrupt

 HamNet/AMPRNet ...
 Of course they can see it, it's a TCP/IP network routed

Again, I'm not talking about encrypting packets and stuffing
them over some simple carrier centered at n-MHz. That's old
tech, and possibly dangerous to the well being of users
noted in the OP before me.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[grarpamp]

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

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

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

There is a spread spectrum radio tech where you broadcast on
essentially all frequencies / wideband at once. To the eavesdropper
it appears as simply a rise in unlocatable background noise levels.
Yet there is a twist... you and your peer posess a crypto key. That
key is used to select and form a broadcast/reception frequency map
over the entire spectrum. You drive it with software radio. Think of the
map as a vertically slotted grille mask over your spectrum analyzer.
The grille spacing/width/overlap is random. What you see is your
distributed signal hidden in the noise. Pass it down your stack
for further processing and decoding.

It's been a while since I've seen this described, whether formally, or
applied. Link to paper[s] covering the topic would be appreciated.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[grarpamp]

On 9/25/13, Rich Jones r...@openwatch.net wrote:
 That kind of technology is already widely deployed in walkie talkies - I
 think I remember at HOPE a speaker mentioning that the NYPD used this
 technique until they abandoned it due to its inconvenience.

 http://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum

I don't think so, if I recall, it seemed to be a further development
of the above
linked idea. There might not have been the usual notion of a coded/shared freq
hopping sequence in which a carrier transmit data. But more like a continuous
parallel broadcast under the mask. Maybe the data was not carried within
the freqs but in the choice of freqs themselves.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[grarpamp]

On 9/25/13, Greg Rose g...@seer-grog.net wrote:
 Even under the much-relaxed export laws of the US, deriving spreading
 information cryptographically is a prohibited export. Which isn't to say it
 is not a good idea.

The US only applies to itself. Further, over the air, it's noise, the crypto
is undetectable and unprovable. And it's (guerilla) software, not physical
commercial product. Nor is this the old 'FCC says you can't encrypt
ham bands' argument/tech.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Matthew Green: An understated response to the NSA and unidentifed friends treachery

[grarpamp]

On 9/6/13, John Young j...@pipeline.com wrote:
 An understated response to the NSA and unidentifed friends treachery:

 http://blog.cryptographyengineering.com/2013/09/on-nsa.html

 More of these expected, many. But who knows, as Green says,
 all could go back to swell comsec business as usual.

Linked from said blog...
http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology

Bull Mountain Technology ... BULLRUN.

Bullshit naming coincidence or genuine cooperative wordplay? ;)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] regarding the NSA crypto breakthrough

[grarpamp]

On 9/5/13, coderman coder...@gmail.com wrote:
 On Thu, Sep 5, 2013 at 11:38 AM, grarpamp grarp...@gmail.com wrote:
 ...
 however, the crypto breakthrough discussed is more mundane:

 Source? Sure, non-PFS can be exploited.

 i asked Snowden for an authoritative copy... ;P

Didn't John just say something about journalists and
interpretation ;)

 But extending that
 as underlying explanation of the Bamford quote is dangerous.
 It's Bamford's quote, ask him.

 there's lots of disinformation around this topic, comparisons and
 analogies that indicate this has been filtered through less technical
 intermediaries.

 he can't say much about specifics, remember?


  deployment of deep packet inspection with SSL/TLS capabilities.[0]

 I'd call it 'applied decrypting' not some breakthrough in
 'cryptanalyze'ing
 or 'break'ing any crypto. Words are important.

 see above regarding technical vs. non-technical.  for the high ups,
 getting access to encrypted communication is breaking encryption.
 whether that is breaking by cooperative agreement and new hardware, or
 breaking by new attacks on crypto primitives themselves, it is
 indistinguishable to them but makes all the difference to us.



 to walk through with rough ballpark but by no means representative numbers

All good extended analysis indeed. Perhaps my issue is just
with the words. I read Bamford as indicating attacks against
the crypto itself, not tricks applied downstream or around it
(regardless of how wholesale, specific, successful or profitable a
given applied approach might be in the eyes of the doers or the done).

While recently novel and profitable with centralized services,
borrowing traditional certs [1] or logging the PFS session keys [2]
is vastly different from having a working cryptanalysis against the
long term thought to be dependable underlings such as
RSA, AES, ECC, etc.

Surely if the cooperation to achieve [1] is so tight then [2] would
be equally doable. Then again, might as well ship the plaintext
straight off the servers.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] regarding the NSA crypto breakthrough

[grarpamp]

On 9/5/13, coderman coder...@gmail.com wrote:
 of all the no such agency disclosures, this one fuels the most wild
 speculation.
 
 James Bamford, a veteran chronicler of the NSA, describes the agency
 

Links to links to source quotes...
http://lists.randombit.net/pipermail/cryptography/2013-June/004477.html
http://lists.randombit.net/pipermail/cryptography/2013-June/004523.html

 however, the crypto breakthrough discussed is more mundane:

Source? Sure, non-PFS can be exploited. But extending that
as underlying explanation of the Bamford quote is dangerous.
It's Bamford's quote, ask him.

  deployment of deep packet inspection with SSL/TLS capabilities.[0]

I'd call it 'applied decrypting' not some breakthrough in 'cryptanalyze'ing
or 'break'ing any crypto. Words are important.


 0. SSL: Intercepted today, decrypted tomorrow , should read SSL:
 Intercepted and decrypted in real-time, almost everywhere

 http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
  less than a third of a percent of SSL/TLS web traffic uses forward
 secrecy!
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] urandom vs random

[grarpamp]

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

Re: [cryptography] urandom vs random

[grarpamp]

On Tue, Aug 20, 2013 at 5:58 PM, Natanael natanae...@gmail.com wrote:
 For all you know the PRNG could be doing nothing more
 than doing SHA256 of a fixed value plus a counter

Yes, and in an application where even that trivial design would serve
to fit some use, testing the apparent randomness.of proposed hash
functions against themselves, and proof sampling operational matters,
would still be useful to do.

To that end, here is one tool that was forwarded off list...
http://csrc.nist.gov/groups/ST/toolkit/rng/index.html
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] urandom vs random

[grarpamp]

 if they had a product, you would have had it.

 It's a recurring theme -- there doesn't seem to be enough market demand for
 Hardware RNGs.

 I once toyed with the idea of creating an open source hardware design

This reminds me, where are the open designs for a strong hwRNG based
on the common smoke detector? People say they want a hwRNG, lots
of them are free for asking right down the street at the demolition site.
But where are the designs?
___
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

[grarpamp]

 On IBM's watch, right.  But the Thinkpads were manufactured by Lenova in
 China well before that;  what IBM sold was the franchise  rights.

And so where does Cisco and Juniper gear come from again... ?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] a Cypherpunks comeback

[grarpamp]

On Mon, Jul 22, 2013 at 3:41 AM, Adam Back a...@cypherspace.org wrote:
 Could you please get another domain name, that name is just ridiculous.

 It might tickle your humour but I guarantee it does not 99% of potential
 subscribers...

 Unless your hidden objective is to drive away potential subscribers.

Though I can't speak directly, I believe it may have been an oversight of
legacy as things come together, and one without particular objective.
You may find the subsequent update below to be more suitable...

https://cpunks.org/pipermail/cypherpunks/2013-July/11.html
 Sat Jul 20 18:39:55 EDT 2013
 Subject: domain change
 ...
 https://cpunks.org/



I can say that Cypherpunks do have a history of flaunting political
correctness (and politics) and that that variety is a welcome and
even necessary thing ;)


 Date: Sat, 20 Jul 2013 12:41:25 -0400
 From: Riad S. Wahby r...@jfet.org
 Subject: a Cypherpunks comeback
 ...
 If you're interested, you can join via
https://al-qaeda.net/mailman/listinfo/cypherpunks
 ...
 So! if you still have an interest in crypto, privacy, and politics, and
 if you want to discuss that interest with a bunch of like-minded weirdos
 from the aether, you can subscribe yourself via the web interface above
 ...
 Here's hoping for another helicopter-free decade.
 ...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Must have seemed like a good idea at the time

[grarpamp]

 A number of projects have been launched to use cell phones as a money
 device, a smart card.  I am pretty sure if your malware can send sms, it can
 transfer funds.

 This not all that fatal, as the money is traceable, but it means that the
 financial institution needs an apparatus to reverse cell phone transactions,
 and that cell phone money is therefore soft on the may scale.

Bitcoin does not necessarily have or desire these properties.
Device security and open devices are important.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Is the NSA now a civilian intelligence agency? (Was: Re: Snowden: Fabricating Digital Keys?)

[grarpamp]

 And when LEA
 get caught doing this nothing terribly bad happens to LEA (no officers
 go to prison, for example).

It is often in the interest/whim of the executive to decline to
prosecute its own,
even if only to save embarassment, so many of these cases will never see a jury.
That's why you need citizen prosecutors who can bring cases before both grand
and final jury. For example, how many times have you seen a LE vehicle failing
to signal, speeding/reckless, with broken running lights, etc... now
try to criminally
(not administratively) prosecute that just as you might be prosecuted for same.

 their own secrecy is the best and
 strongest (though even then, not fail-safe) guaranty of non-use for
 criminal investigations.

Didn't the requisite construction of plausible paths from tainted seed just
get covered. So, No! The only guaranty against secret taint is transparency.
Try removing the 'non-' next time.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

 I think if Tor had an arbitrary queue with store and forward as a high
 latency module of sorts, we'd really be onto something. Then there would
 be tons of traffic on the Tor relays for all kinds of reasons - high and
 low latency - only to all be wrapped in TLS and then in the Tor protocol.

That would work for things you're able to 'encapsulate' within some
compatible form of transmission. Email is essentially a single message
in one direction. Various stackable modules could be apply to certain
compatible things... random delay, storage at some prescribed levels
of redundancy, add/remove padding, etc.

Also of issue is if, when or where you're required to interact with clearnet.
TCP and websites do not like any of these modules. They'll timeout
or break. And you'd need a huge application specific volunteer army
writing clearnet interface modules for each BBS, website app, etc.
Which few would use since they need access tokens and exits
can't be trusted (though see below if you would so choose to).

But if you're able to throw out old models, things are possible, particularly
over/within your own transports... for example, I2P-Bote.

There may even come a time where you can view these overlays
as your own implicitly trusted execution platform into which you
launch a command packet/agent whose parameters will be followed
according to various rules on your behalf.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Is the NSA now a civilian intelligence agency? (Was: Re: Snowden: Fabricating Digital Keys?)

[grarpamp]

 Whereas the
 incentive to keep the secret from spilling is so strong that it should
 act as a moderator on its operators.

... against use outside of its original scope/parties. I can see that.
Time and history tends to expose everything though. And in the present,
not knowing what we don't know makes these models hard to evaluate.

 Sorry for the OT chatter.

Similarly, guilty here as well. Off like a Spartan to Cali :)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Is the NSA now a civilian intelligence agency? (Was: Re: Snowden: Fabricating Digital Keys?)

[grarpamp]

 id like to say these fellas are decent men

True for sure. Yet sometimes when you assemble large systems of
even the best of men, those systems may drift from or not always
retain the fine character of its components. A weakness of humanity
perhaps.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Snowden: Fabricating Digital Keys?

[grarpamp]

 that if Snowden has access to them - other people who wish to have
 access may also have these document - too bad none of them seem to care
 to educate the public or to expose the incredibly illegal interpretation

The incidence/depth of leakers/leaks over time seems to be increasing.
Whether or not the outcome of this particular one will change that
remains to be seen. There could be a bit of wait and see going on here.

 Snowden himself said that these controls are irrelevant - his leaks are
 ...
 1) More detail on how direct NSA's accesses are is coming
 ...
 He clearly doesn't think that privacy by policy is as effective as
 privacy by design - where by design, he clearly endorses the use of
 cryptography with the caveat that NSA breaks into computer systems:

 Encryption works. Properly implemented strong crypto systems are one of
 the few things that you can rely on. Unfortunately, endpoint security is
 so terrifically weak that NSA can frequently find ways around it.

A note: this was a quote in the context of users asking if their use of
crypto would defeat the NSA, not as to internal NSA policy/application.

Even under what might be this new post 911 open sharing model,
it would seem reasonable to assume that information regarding
actual cryptanalysis capabilities would be compartmented [perhaps
far and securely] away from the areas that have produced the current
stream of news stories. There hasn't been much said of those capa's, no?

 After more than a decade of talking with
 people about these issues, it is incredible to see this shift happen and
 it was nearly over night for some people!

Unfortunately, unlike those with their ear to the ground for these
sort of things (which really doesn't require any hearing aid to
begin with), some people just refuse to get it until it's on
newsprint in front of them. Now they're begging for help to the
very same people they laughed off earlier. As much as we might
want to say get lost, it still feels good to finally be recognized
as having been right all along. And the advice is still the same
in general: encrypt everything.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

 There should be a disclaimer somewhere that Tor is a competitor to I2P, is 
 far from perfect itself (actually has a few glaring weaknesses, such as exit 
 nodes), and the guy critiquing I2P works for Tor.

There should be a table somewhere that shows that
all these different systems have different *features*.
One such feature is exit to clearnet, which is not in
itself a 'weakness' unless further supporting information
as to how the feature is broken, not its mere presence,
is supplied. Note also that I2P 'exits' as well, albeit
from one of any particular list of known exits configured
by the user. Furthermore, such wikitable could very
well include actual weaknesses, whether by design
limitations/concessions or work in progress.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[grarpamp]

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

I would bet that Phantom both ran out of developer time and
has discouraged further takeup by using the unfamiliar
HESSLA instead of say the simply free 2-clause BSD.

As opposed to having been proven to use an [unfixably]
flawed protocol design, no? (this being more on topic).
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography