Jeffrey Walton | 29 Jan 23:23 2016

NIST SP 800-90 B, Random Bit Generators Recommendation for the Entropy Sources Used for Random Bit Generation
John Young | 22 Jan 20:53 2016

NSA Spy-by-Crypto

DIRNSA said at Atlantic Council on 21 January that NSA spying ("intelligence")
and information protection (IAD) to be meshed. Separation not suitable for
current requirement.

Outside partners to aid dual tech: spy-by-crypto.
travis+ml | 19 Jan 08:14 2016

a user's request for usable storage crypto

-- | if spammer then john@...
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977
travis+ml | 19 Jan 00:23 2016

gfverif, djb's ECC bugfinder

(Humorous logo of Evariste Galois and a checkmark elided)

Cryptographic software needs to be correct: even a tiny bug can have
disastrous consequences for security, as illustrated by Brumley,
Barbosa, Page, and Vercauteren exploiting an ECDH carry bug in OpenSSL
0.9.8g. Standard software-testing techniques catch many bugs but did
not prevent, e.g., further OpenSSL carry bugs announced in January
2015 (initial analysis: too expensive to exploit) and December 2015
(initial analysis: exploitable by well-equipped attackers).

The goal of gfverif is to integrate highly automated proofs of
correctness into the ECC software-development process. These proofs
can be compromised by bugs in gfverif, but eliminating those bugs is a
relatively small one-time task. Correct proofs will eliminate all ECC
software bugs, including the low-probability carry bugs that slip past
testing. Of course, bug-free software can be compromised by hardware
bugs and compiler bugs, but separate projects are underway to
eliminate those bugs.


We have proven the correctness of a reference implementation of X25519
elliptic-curve scalar multiplication. The implementation is, except
for a few minor tweaks, the preexisting "ref10" implementation in
C. Correctness means that, under plausible assumptions regarding the
behavior of the C compiler, the implementation computes exactly the
function specified by a concise high-level description of X25519.

(Continue reading)

travis+ml | 17 Jan 10:21 2016

a new blockchain POW proposal

So I'm sure I'm not the first person to muse on the mining POW problem
and its lack of social value apart from being hard.  Let me lay out a
few links I've been reading in my "copious" free time and risk
sounding naive by musing a bit.  Hopefully those of you with more
knowledge can correct me and/or send me to even better references.

I'm sure those of you in the know have heard this polemic:

I'm not trying to inflame opinions on the matter, it seems they
already have been and I'm not trying to throw fuel on the fire,
and I really don't know enough about the technical details to
know why a block size matters all that much, but I am somewhat
astonished at 7 tps as an upper bound.

What I do believe is that brute forcing partial hash preimages has
virtually no useful benefit.  The fact that we have the world's
largest computing cluster solving a useless problem sounds like
something out of a Douglas Adams novel.

If we were enumerating solutions to NPC problem then the block chain
would be useful for any isomorphic NP problems, and any optimizations
would apply to all NP problems.

From what I hear, it's just local hydro, the power is basically free,
and it's currently controlled by two guys from China (a handful of
people control 95% of the mining power, IIRC). But it could be solving
useful problems. For example one day gcc could query the block chain
for register allocation solutions.
(Continue reading)

John Young | 12 Jan 22:28 2016

Sign the Letter to Secure the Internet

Sign the Letter to Secure the Internet

Via Henry Baker, Cryptography List
Michael Nelson | 11 Jan 04:40 2016

Re: What do ya'll think about this ?

I petered out of enrolling in the nimbusid demo, partly because it was work, and partly because I did not want
to give up private info about myself, or bother inventing reproducible fiction.

Probably the best way to understand it is the video on the main page, "What is NimbusID?"

You basically tell them about parts of your life -- places and people, and things.  This creates a tuple:
(someone's name, location, relationship, occupation).  Login challenge is they present you with a few
alternatives one after another. Eg, they present you with a few names. You choose the one you recognize. 
Then they present you with a few locations. Etc. If you make your way through the tree and nail the original
tuple in the cross-product, you are authenticated. At least I think this is what they do.

To deal with the limited amount of password space being reused, they say: "the system will periodically
collect new information from the user", and "this information if recycled as noise information for other users".

A few observations:

One notes that being asked periodically for new information could be tedious.

Also, the problems with personal information (and also biometrics) are well-known. True stuff about
yourself can be learned by someone else, and then used, if it is a credential. The stuff also can be stolen if
entrusted to a database somewhere, and unlike a password, can't be changed.

To make realistic false data that is hard for an attacker to distinguish from the true data, they recycle
other people's data. Presumably they change it a bit... But even so, a small amount of statistical
information leaks.

There are plenty of knowledge-based authentication systems. These guys seem to have a sequence of
questions where each subsequent question depends on the former. Most KBA involves independent Q-A
(Continue reading)

Brian Hankey | 5 Jan 23:37 2016

What do ya'll think about this ?
Antonio Sanso | 5 Jan 15:21 2016

What the heck is RFC 5114?

Comments/answers are welcomed :)


Jeffrey Walton | 1 Jan 08:55 2016

OT: Wanted: Cryptography Products for Worldwide Surve

From Schneier's CRYPTOGRAM

In 1999, Lance Hoffman, David Balenson, and others published a survey
of non-US cryptographic products. The point of the survey was to
illustrate that there was a robust international market in these
products, and that US-only export restrictions on strong encryption
did nothing to prevent its adoption and everything to disadvantage US
corporations. This was an important contribution during the First
Crypto War, and Hoffman testified before a Senate committee on his

I want to redo that survey for 2015.

Here, at the beginning of the Second Crypto War, we again need to
understand which encryption products are outside the reach of US
regulation (or UK regulation). Are there so many foreign crypto
products that any regulation by only one country will be easily
circumvented? Or has the industry consolidated around only a few
products made by only a few countries, so that effective regulation of
strong encryption is possible? What are the possibilities for
encrypted communication and data storage? I honestly don't know the
answer -- and I think it's important to find out.

To that end, I am asking for help. Please respond in the comments with
the names -- and URLs -- of non-US encryption software and hardware
products. I am only interested in those useful for protecting
communications and data storage. I don't care about encrypting
financial transactions, or anything of that sort.

(Continue reading)

Jeffrey Goldberg | 30 Dec 08:24 2015

Re: Hi all, would like your feedback on something

On Dec 23, 2015, at 2:18 AM, Brian Hankey <bhankey@...> wrote:
> I sent a long winded reply that has been stuck in moderation for a couple of days

I believe that this is because your are sending email with a text/html part. Most mailing lists will reject
such things.

>> Ah, so you want the user to remember something specific for each site.

> No… remember a rule that can be used to transform the name of the site in some way.

So the attacker only needs to discover this rule once. And the rule is going to be the same sorts of things that
crackers already use. You’d be surprised at how many passwords in the LinkedIn dataset were things like Iink3d1n

Crackers would barely be need to change their transforms to go after that.

And once they’ve cracked one of them, they will know your rule for all of them.

>>> Not a master password and not simply “site name” could be as follows:  Perform a transform on the site
name, one that is easy to remember but hard to guess.  It seems to me there could really be a lot of variations
here still.
>>> Char for letter substitutions, exclude vowels, double vowels, exclude consonants, double
constants, cases, do you include or not include the subdomain, do you include or not include the top level
domain, do you include the (.), do you append anything to it and so on.
>> Each one of those decisions is roughly one bit (except for “what you append”). So you’ve got 8 bits
in there, if you are equally likely to choose each alternative (say, flip a coin for each decision).
>> A am going to guess that if people are expected to remember scores of these, they will make the same
(Continue reading)