Re: [cryptography] Fwd: [RFC][PATCH 0/6] /dev/random - a new approach

[James A. Donald]

On 2016-04-28 3:49 AM, Watson Ladd wrote:

If only there was an asymptotically good design that didn't require
any estimation at all. See
https://www.schneier.com/cryptography/fortuna/ for details.



The money shot is:
"At first, it might appear that the only way to prevent this attack is 
by discovering a sound way to estimate the current entropy in the state 
and to use this estimate to block the premature next calls. This is
essentially the approach taken by Linux’s /dev/random and many other 
RNGs with input. Unfortunately, sound entropy estimation is hard or even 
infeasible [SV03, FS03] (e.g., [DPR+13] showed simple ways to
completely fool Linux’s entropy estimator). This seems to suggest that 
the modeling of RNGs with input should consider each premature next call 
as a full state compromise, and this is the highly conservative
approach taken by [DPR+13] (which we will fix in this work). Fortuna. 
Fortunately, the conclusion above is overly pessimistic. In fact, the 
solution idea already comes from two very popular RNGs mentioned above, 
whose designs were heavily affected by the desire to overcome the 
premature next problem: Yarrow (designed by Schneier, Kelsey and 
Ferguson [KSF99] and used by MacOS/iOS/FreeBSD), and its refinement 
Fortuna (subsequently designed by Ferguson and Schneier [FS03]
and used by Windows [Fer13]). The simple but brilliant idea of these 
works is to partition the incoming entropy into multiple entropy “pools” 
and then to cleverly use these pools at vastly different rates when 
producing outputs, in order to guarantee that at least one pool will 
eventually accumulate enough entropy to guarantee security before it is 
“prematurely emptied” by a next call."



Which however still means that calls to produce valuable keys shortly 
after boot are going to fail.


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

Re: [cryptography] Fwd: [RFC][PATCH 0/6] /dev/random - a new approach

[James A. Donald]

Thor Lancelot Simon  on Wed, Apr 27 2016:

So we eat things like the first several seconds of frames from
the network; dmesg output; TOD; IP addresses; hostnames; and other
configuration and nonsecret data [...]


On 2016-04-28 3:19 AM, Sven M. Hallberg wrote:

Nice. I think this highlights how a hang-up on entropy estimation has a
chilling effect. Sources that cannot be reliably estimated to provide
"true randomness" are discounted and end up unused.


Entropy, like economics, is about counterfactuals, where what might have 
happened matters as much or more than what actually did happen.


Thus, estimating entropy is like making economic predictions.  You 
discover that your Nobel prize winning economist is outperformed by a 
gipsy communing with demons.


If we think we need an accurate, rather than qualitative, estimate of 
entropy, maybe we need to rearrange our affairs so that a qualitative 
estimate will suffice.


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

Re: [cryptography] a new blockchain POW proposal

[James A. Donald]

On 2016-01-24 1:11 PM, ianG wrote:

There's some thinking about sharding the blockchain because that's the
only way to go massively scaled to say IoT levels.  Also a lot of
thinking as to what happens when you relax the anonymity condition.


Need to shard the blockchain if we are going to replace the US dollar, 
if everyone in the world starts using a cryptocurrency to buy eggs and milk.


Need to go proof of stake as it has become apparent that the interests 
of miners are not perfectly aligned with the interests of the bitcoin 
business community.


Unfortunately, these things are easier said than done.  Hard to figure 
out how to shard the blockchain and still efficiently solve the 
Byzantine Generals problem every few minutes.  I have been puzzling at 
this for some time.  Seems as if it should be doable, and indeed it is 
easy to find a seeming solution 
http://blog.sldx.com/three-challenges-for-scaling-bitcoin/, but it 
always turns out that the seeming solution makes it possible for someone 
to profit from bad behavior.  It is hard to shard the blockchain while 
having incentives aligned in every shard. To shard the blockchain we 
need global alignment of incentives with merely local knowledge.


Simple proof of stake solutions turn out to require considerably more 
work than the current proof of work solution.


I still think this is doable, but it is tricky.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] a little help with cookies please

[James A. Donald]

On 2015-09-16 11:40, Givon Zirkind wrote:

is it correct that [web page] cookies are trully local?


Web page cookies are always sent to the server.

And what is truly evil is that umpteen different websites may include a 
link to google, which sends google the google cookies, so that google 
knows that it is the same person on many different websites.


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

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

[James A. Donald]

I was actually surprised how uncompressible the timedelta stream



does not make any sense. the result of a complex recursive chaotic
calculation always appears uncompressible, unless you know the proper
underlying model. trying to compress it only puts an upper limit on
entropy, but never an estimation, let alone lower bound.


Exactly so.  Because entropy is measured over counterfactuals, it can 
never be known from observation, only from theory.


Which is sort of weird, seeing as there is something observable about 
the fact that things run down and fall apart.


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

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

[James A. Donald]

On 2015-05-27 22:14, Krisztián Pintér wrote:

On Wed, May 27, 2015 at 3:12 AM, Russell Leidich pke...@gmail.com wrote:

if your proposed method comes with a complex extractor, it is bullshit

OK point well taken. I should offer a raw mode.


no, you actually shouldn't. you should offer raw mode only. maybe some
clever compression just to reduce the amount of data going into the
slower secure whitening.


What this leaves behind is the aperiodic residue. Or more specifically,
((the hashes (of all sequences)) that have not been seen in the last 2^16
such hashes). I realize that this isn't hard proof (as nothing in physical
hardware can be proven)


this is much worse than not a hard proof. it is next to nothing. you
have a hypothesis, which you don't clearly state, and then you have a
countermeasure, which you don't explain.



cache misses, pipeline stalls, CPU circuit clock gating, etc. that provide
the majority of the protoentropy.


the CPU is a deterministic system. cache misses and all the other
stuff are not random, but depend on previous instructions, thus the
internal state of the cpu. this is NOT a source of entropy. the source
of entropy comes from outside of the CPU, namely anything that changes
its internal state. these are: responses from mass storage or other IO
drivers, user input, network events, etc. that is: IRQs. the CPU as a
system is chaotic, and so tiny differences in those inputs cause huge
differences later. but this is NOT entropy. this is a completely
deterministic process.


The system can be thought of as pseudorandom number generator that is 
continually seeded by a small amount of true randomness.


But it truly is seeded by a small amount of true randomness.

How much true randomness is an empirical question.  I rather think that 
for normal systems, connected to the internet and physical disk drives, 
that is quite a lot of true randomness.


If on the other hand, your system is booting up from ROM, then early in 
the boot process, not much.



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

Re: [cryptography] Unbreakable crypto?

[James A. Donald]

On 2015-03-22 10:34, James A. Donald wrote:

On 2015-03-22 06:13, Lee wrote:

Would a commonly available large binary file make a good one-time pad?
Something like ubuntu-14.10-desktop-amd64.iso12 maybe..


I wrote:

Before you asked the question, probably would have made a good one time
pad.

Not any more.


Of course, it was never really a one time pad, merely security by 
obscurity - which is quite good, until it is quite bad.


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

Re: [cryptography] random number generator

[James A. Donald]

On 2014-11-22 03:01, d...@deadhat.com wrote:



Rather than me listing names, why not just let it rip and run your own
randomness tests on it?


Because that won't tell me if you are performing entropy extraction.

Jytter assumes an x86 machine with multiple asynchronous clocks and
nondeterministic physical devices. This is not a safe assumption. Linux
assumes entropy in interrupt timing and this was the result
https://factorable.net/weakkeys12.extended.pdf.

This falls under the third model of source in my earlier email. Your
extractor might look simple, but your system is anything but simple and
entropy extracted from rdtsc and interrupts amounts to squish.

Looking at the timing on your system and saying it looks random to me
does not cut it. Portable code has to have a way to know system timing is
random on every platform it runs on. The above paper shows that it isn't.

Jytter does something neat but the broad claims you are making and the
broader claims the Jytter web site makes do not pass the sniff test.



By and large, usually, interrupt timing is somewhat random, and, if not 
random, unknowable to the adversary.


But this is not guaranteed, and likely to be untrue if you have several 
identical systems, such as routers, which need randomness at boot up. 
All your routers are likely to wind up generating keys from a rather 
small set of possible keys.


It is extremely easy to get true randomness, or at least randomness 
unknowable to the adversary.  It is extremely hard to get true 
randomness reliably in an unknown or arbitrary system.  You really have 
to tinker your entropy collection to your situation, to your particular 
system.


128 bits of entropy is enough for forever, so the big problem is start up.

A long running system is bound to have plenty of entropy - anything more 
than 128 is plenty.  So if it writes a unique secret key to each boot up 
image, and each boot up has access to a good approximation to the 
current time, we are golden.



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

Re: [cryptography] random number generator

[James A. Donald]

On 2014-11-22 06:31, d...@deadhat.com wrote:

OK, if you think my Jytter TRNG is weak,


I did not say it was weak. I said Jytter (and any other algorithm) is
deterministic when run on an entropy free platform. This is a simple fact.


All platforms have entropy.

If they boot from a physical disk, microturbulence creates true 
randomness in data availability.


If they are on the net, packets arrive at random times with random delays.

If they are using wifi, not only are packets arriving at random times, 
but are affected by random noise.


The question is, does all this entropy show up in Jytter?  I rather 
think it does.

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

Re: [cryptography] random number generator

[James A. Donald]

On 2014-11-23 09:47, Russell Leidich wrote:

in your case, hash 128+N samples to get, say, 127.99 bits of entropy
per hash output. N is small, under 20 I think.

Yeah this certainly inspiring with respect to milking decent entropy
from coldbootish environments. If we assume the use of a good hash,
then the problem reduces to one of asking how much entropy a sample is
worth.

But this is where Pandora's box opens up: modern systems -- even mobile
phones -- are so complicated that autopseudorandomness can look very
convincingly like a TRNG. For instance, we could have predictable cache
stalls, bus stalls, pipeline stalls, etc. which interact like a decent
PRNG in order to render the appearance of physical entropy even in the
absence of interrupts. But we could still end up with a painfully narrow
set of possible outputs, which would still be too large to perceive. For
instance, our 128-bit random number might be worth only 70 bits, so we
likely wouldn't detect that weakness until it comes back to bite us in
the future.


If there is any true randomness in the system, autopseudorandomness will 
mix it with everything else, and so Jytter will collect it.


But in coldboot system, there may well be very little true randomness.

So, every boot image should have its own unique 128 or 256 bit secret 
unpredictable to an adversary.


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

Re: [cryptography] The Trouble with Certificate Transparency

[James A. Donald]

I don't know how google proposes to do it.  I don't find their 
explanation entirely clear.


Here is how I would do it.  It guarantees that everyone sees the same 
information, and any attempt to tell two different stories immediately 
gets caught.


There will be a mapping between strings and hashes, and you can look up 
the 32 byte hash corresponding to a string.


The strings will be email addresses and the urls of websites.

The hash will be a hash of assertions about the website made by the 
owner, the currently valid public keys of the website, and the past 
history of changes in this information.


Updates take effect once a day or so. If you change this information, 
you will not see the change for a day or so.  Thus if you want to update 
your key, first add an additional key.  When that propagates, update 
your website, then remove the old key.


There is a global hash that represents the root of a tree of all hashes, 
and the past history of global hashes.


To prove that the value you just looked up is the same for everyone, 
look at the chain of hashes connecting it to the root of the tree of all 
hashes.


To lie to you, to give one story to the owner, and a different story to 
you, the global hash would have to be different for the owner and for you.


A lot of people observe the global hash, and its history.  So you check 
with one of them, to make sure you are seeing the same global hash as 
they do, and they similarly check with each other.



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

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

[James A. Donald]

On 2014-07-29 02:23, Lodewijk andré de la porte wrote:

Hey everyone,

If I XOR probably random data with good enough random data, does that
result in at least good enough random data?


Yes, but other mixing functions are better.

Best to hash all streams together, rather than xor them together.  Then 
if there is any random difference between two imperfectly random 
streams, the resulting stream will be more random than either one.


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

Re: [cryptography] Silent Circle Takes on Phones, Skype, Telecoms

[James A. Donald]

On 2014-07-11 07:45, Kevin wrote:

On 7/10/2014 4:39 PM, John Young wrote:

https://blog.silentcircle.com/why-are-we-competing-with-phone-makers-skype-and-telecom-carriers-all-in-the-same-week/


With silent circle, when Ann talks to Bob, does Ann get Bob's public key 
from silent circle, and Bob get Ann's public key from silent circle.


If they do it that way, silent circle is a single point of failure which 
can, and probably will, be co-opted by governments.


If they don't do it that way, how do they do it.

Obviously we need a hash chain that guarantees that Ann sees the same 
public key for Ann as Bob sees for Ann.


Does silent circle do that?

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

Re: [cryptography] Silent Circle Takes on Phones, Skype, Telecoms

[James A. Donald]

On 2014-07-11 20:59, Michael Rogers wrote:

For phone calls they use ZRTP, so Ann and Bob can verbally compare
short authentication strings after the key exchange to detect a MITM,
*if* they know each other's voices and their voices can't be faked.
ZRTP carries keying material forward from one session to another so it
isn't necessary to do this every time.

For messaging it's the same, except the verbal confirmation happens
out-of-band. The protocol spec seems to have been taken offline
recently, but it's archived here:

https://web.archive.org/web/20140125121552/https://silentcircle.com/static/download/SCIMP%20paper.pdf


If it takes more than one click, end users are not going to do it.


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

Re: [cryptography] Request - PKI/CA History Lesson

[James A. Donald]

On 2014-04-30 02:14, Jeffrey Goldberg wrote:

On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote:


Cannot outsource trust  Ann usually knows more about Bob than a distant 
authority does.


So should Ann verify the fingerprints of Amazon, and Paypal herself?


Ann should be logging on by zero knowledge password protocol, so that 
the entity that she logs on to proves it already knows the hash of her 
password.


ZKPP has to be in the browser chrome, not on the browser web page.

 How do you see that working assuming that Ann is an �ordinary user�?

To the ordinary user, should not behave any different, and should only 
look different in that the ZKPP login screen looks different from any 
possible web page in a way that is quite difficult to fake for any 
software that does not already have total control of the users machine.


Details of how to achieve unfakeable logon screen appearance depend on 
OS version.  To make the ZKPP logon screen in Windows 7 different from 
any possible web page, have the browser web page vanish when the 
browser's genuine ZKPP logon screen is up.  Analogous but different 
gimmicks are feasible in other operating systems and system versions.


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

Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL

[James A. Donald]

On 08/04/14 11:46, ianG wrote:

We have here a rare case of a broad break in a security protocol leading
to compromise of keys.


On 2014-04-09 21:53, Alan Braggins wrote:

Though it's an implementation break, not a protocol break.


Not exactly.  The protocol failed to define a response to nonsensical 
records.  The bug was that the protocol responded to invalid records the 
same way as if they were valid.


The protocol should have said  a valid record shall satisfy the 
following requirements.  Invalid records shall be silently discarded and 
all actions that depend on them silently terminated.



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

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

[James A. Donald]

On 2014-04-09 00:48, Nico Williams wrote:

On Mon, Apr 07, 2014 at 11:02:50PM -0700, Edwin Chu wrote:

I am not openssl expert and here is just my observation.
[...]


Thanks for this analysis.

Sadly, a variable-sized heartbeat payload was probably necessary, at
least for the DTLS case: for PMTU discovery.

Once more, a lack of an IDL, standard encoding, and tools, has hurt us.
Hand-coded parsers/encoders are disasters waiting to happen.


Is there an existing idl for messages such that interface descriptions 
that can be compiled into parsers and encoders?


(microsoft's idl is inherently function oriented, rather than message 
oriented, leading to disastrous results when they somehow stretched it 
for message passing environments)

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

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

[James A. Donald]

On 2014-01-17 01:28, John Young wrote:

Civil engineers never say a dam is infallible, they say it will fail, watch
for well-known weak spots, prepare to patch and maintain continuously,
and never forget the disasters of over-confidence, limited construction
budgets, cut backs in maintenance, and water policy exploiters.


The relevant analogy is not that a dam might fail, but that the builders 
were paid ten million dollars to make sure it failed when the town's 
enemies wanted it to fail by planting dynamite in the dam.


This is not business as usual.  We will not continue in this path.  We 
will not continue to use dam builders who put dynamite in their dams.


People are not going to accept RSA solutions, and they are not going to 
accept IETF solutions.


You cannot just say that shit happens, and continue business as normal. 
 That is not going to fly.


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

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

[James A. Donald]

On 2014-01-15 02:12, John Young wrote:

Shirley Jackson, The Lottery, sacrificing  a victim purges guilt
of the guilty.

Does anyone really believe RSA is alone in this betrayal?

And that making an example of RSA will stop the industry practice
of forked-tonguedness about working both sides of the imaginary
fence of dual-use, dual-hat, duplicity of comsec?


Yeah, it will.  Open source the cryptographic part of your product, and 
don't use RSA, IETF, or NIST standards.



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

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

[James A. Donald]

On 2014-01-15 10:48, John Young wrote:

But open source is compromised as well, for the same reasons
and by the same parties. Some claim open source was born of and
is powned by the spies.


We can audit open source.  Of course that costs serious money, but some 
people have adequate incentive to do so.


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

Re: [cryptography] Practical Threshold Signatures

[James A. Donald]

On 2013-11-13 16:14, realcr wrote:

2. Can I actually trust the elliptic curve with weil pairing to do its
cryptographic job? Maybe better asked: Can I trust it like I trust that
it is hard to factor numbers? (Maybe even more?)


The Weil pairing is a great big hole in our usual arguments that most 
elliptic curves are strong.


The usual arguments that it is likely to be hard to solve the discrete 
log problem for elliptic curves do not apply to an elliptic curve with a 
Weil pairing.


Samuel Neves sounds like he understands enough maths to discern what 
qualifies an elliptic curve with a Weil pairing to be strong, but I do not.





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

Re: [cryptography] Practical Threshold Signatures

[James A. Donald]

On 2013-11-13 16:14, realcr wrote:

 From what I understand, the group I'm looking for is an elliptic cure
with a weil pairing. (Jonathan mentioned bilinear map, I assume that
means the same thing?)


A pairing is a bilinear map.  The Weil pairing is a particular bilinear 
map on the points of certain elliptic curves that is useful for 
cryptography.


So, same thing, near enough.

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

Re: [cryptography] was this FIPS 186-1 (first DSA) an attemped NSA backdoor?

[James A. Donald]

On 2013-10-10 23:30, Adam Back wrote:Of course NIST is down due to the
USG political level stupidity (why take the extra work to switch off 
the web

server on the way out I dont know).


Note that the obamacare websites are still open, and that parks that are 
normally operated by private contractors who normally pay rent to the 
government for their concession stands now have government employees 
present to prevent people from operating them.


So chances are that NIST is still busily plotting against security, but 
has turned of outside access to its websites.


It would seem that the 85% of government that is still operating is the 
part that no voters will notice, and the 15% that is shut down is the 
part that voters are likely to notice, and, the government hopes, put 
pressure on the Republican party.


Logically therefore, we should shut down the 85%, and keep the 15% open.



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

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

[James A. Donald]

On 2013-10-06 02:52, d...@geer.org wrote:

We reject: kings, presidents and voting.
We believe in: rough consensus and running code.


Which gave us IEEE 802.11

Which, like Occupy Wall Street, worked by consensus.


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-05 10:44, Jeffrey Walton wrote:

On Thu, Oct 3, 2013 at 10:32 PM, James A. Donald jam...@echeque.com wrote:

On 2013-10-04 11:41, Jeffrey Walton wrote:

We could not get rid of Trustwave in the public sector (so much for
economics).

What is wrong with trustwave?

The company operates in an industry where trust is a commodity. The
company violated the trust,which essentially means they have no
product. Rewarding bad behavior was the last thing that should have
happened.


Trustwave should have had its certificate authority revoked from 
browsers, but it is not in the CA business.  It is in the spying 
business, not in the trust business, but in the distrust business. The 
scandal is not that it abused its CA authority, but that it was given CA 
authority.  Trustwave spies.  That is its job.  Soldiers kill people and 
break things.  That is their job.


Trustwave's behavior is not scandalous.  Mozilla playing footsie with 
trustwave is scandalous.



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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-03 19:16, coderman wrote:

On Wed, Oct 2, 2013 at 5:49 PM, James A. Donald jam...@echeque.com wrote:

...
So, people who actually know what they are doing are acting as if they know,
or have good reason to suspect, that AES and SHA-2 are broken.


James this is not true.

i challenge you to find reputable positions backing this assertion.
where know what they are doing and reputable mean cryptographers
who design and implement block ciphers and secure digests.



http://silentcircle.wordpress.com/2013/09/30/nncs/

Jon Callas is a cryptographer who designs and implements block ciphers 
and secure digests - the skein hash and three fish.


He does not believe that AES and SHA-2 rest are necessarily broken - but 
neither does he believe that they are not broken.

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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-03 21:56, coderman wrote:

On Thu, Oct 3, 2013 at 4:28 AM, James A. Donald jam...@echeque.com wrote:

...
He does not believe that AES and SHA-2 rest are necessarily broken - but
neither does he believe that they are not broken.


there is a significant difference between avoiding a cipher on principle,
  or association, or abundance of caution, or to avoid proving a negative,

and avoiding a cipher because it is broken.


To avoid proving a negative

Means to avoid the need to prove it is not broken

And why do we need to prove it is not broken?  Because we do not trust 
the people who issued it.



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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 02:03, Jared Hunter wrote:

One of the biggest issues we're wrestling with, I think, is that the crypto 
community already decided that AES and SHA-2 are just fine.


In large part because we trusted NIST.  If we do not trust NIST ...


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 00:13, Jeffrey Goldberg wrote:

So unless you and Silent Circle have information that the rest of us don�t 
about AES and SHA-2, I�m actually pissed off at this action. It puts more 
pressure on us to follow suit, even though such a move would be pure security 
theater.


You have to get off the NIST curves.  If getting of the NIST curves, 
might as well get off AES and SHA-2 as well.


If you are not using the NIST curves, the need to change is less urgent.


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 07:31, Jon Callas wrote:

absolutely, this is an emotional response. It's protest. Intellectually, I 
believe that AES and SHA2 are not compromised. Emotionally, I am angry and I 
want to distance myself from even the suggestion that I am standing with the 
NSA. As Coderman and Iang put it, I want to*signal*  my fury. I am so pissed 
off about this stuff that I don't*care*  about baby and bathwater, wheat and 
chaff, or whatever else. I also want to signal reassurance to the people who 
use my system that yes, I actually give a damn about this issue.
By moving away from anything NIST has touched he deprives the NSA of 
leverage to insert backdoors, contributing to the general good, from 
which his company, and thus himself also benefits. By opposing the NSA, 
he gives his company credibility that they will not secretly play footsy 
with the NSA behind closed doors, reassuring his customers and 
contributing to the particular good of his company and himself.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] A question about public keys

[James A. Donald]

On 2013-10-04 03:45, Adam Back wrote:
Is it just me or could we better replace NIST by DJB ? ;)  He can do 
that EC

crypto, and do constant time coding (nacl), and non-hackable mail servers
(qmail), and worst-time databases (cdb).  Most people in the world 
look like

rank amateurs or no-real-programming understanding niche-bound math geeks
compared to DJB!


Committees are at best inherently more stupid than their most stupid 
member, and are at worst also inclined to evil and madness.  Linux was 
success because Linus is unelected president for life.


Let us have Jon Callas as unelected president for life of symmetric 
cryptography, Bernstein as God King of public key cryptography.


Recall the long succession of Wifi debacles.  Has any committee ever 
done anything good in cryptography?


IEEE 802.11 was stupid.  If NIST  was not stupid, it was because evil 
was calling the shots behind the scenes, overruling the stupid.



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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 08:04, Paul Wouters wrote:


Reasoning that way, you're very quickly left with not but a tin foil
hat. Let's say we agree on twofish. then NIST/NSA certifies it for FIPS.
Are we than taking that as proof it is compromised and figure out
something else?


If people were adopting twofish Jon Callas did so, reason to believe in 
twofish.  If people were adopting twofish because NIST was doing it, 
that would be reason to doubt twofish.


If all shall follow Jon Callas as unelected president for life of 
symmetric cryptography then NIST is powerless, therefore irrelevant.  If 
it does not set standards, cannot corrupt them.


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 11:41, Jeffrey Walton wrote:

We could not get rid of Trustwave in the public sector (so much for
economics).


What is wrong with trustwave?  They are smart people, unlike the world 
bank economists who do not know the difference between negative feedback 
and positive feedback, or the IEEE 802.11



There's no way we can get rid of the US agency responsible
for crypto standards


If no one pays attention to their standards, we have gotten rid of them.


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-04 11:26, Jeffrey Goldberg wrote:

But not using AES is a protest that hurts only ourselves.


I have always been inclined to believe that that twofish is better than AES.

Refusing to use AES, or making it the non default choice, is rejecting 
NIST as a standards body.


We need to reject NIST as a standards body.


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

Re: [cryptography] One Time Pad Cryptanalysis

[James A. Donald]

On 2013-10-03 09:17, Charles Jackson wrote:


Any academic references?



Official reality is surreal and generally should be ignored.


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

Re: [cryptography] the spell is broken

[James A. Donald]

On 2013-10-03 04:50, d.nix wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Yeah, it may well be just marketing. The one thing that gives me pause
is that Callas and Schneier are both part of the team that worked on
the systems they have chosen to migrate to (Twofish, Skein), and
Schneier is one of the very few people to see the Snowden docs (or
some subset thereof).



So, people who actually know what they are doing are acting as if they 
know, or have good reason to suspect, that AES and SHA-2 are broken.



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

Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)

[James A. Donald]

On 2013-10-02 06:10, Tony Arcieri wrote:
tinfoilhatThey wanted us to think they were incompetent, so we would 
expect that Dual_EC_DRBG was their failed attempt to tamper with a 
cryptographic standard, and so we would overlook the more sinister and 
subtle attempts to tamper with the NIST curves/tinfoilhat�


The NSA is conspiratorial.

The NSA, in choosing the NIST curves, chose them in one way and said it 
was choosing them in another way.


One lie, all lies.

If a liar, looking for consistency is pointless.


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

[cryptography] Why non random EC curves are unacceptable.

[James A. Donald]

Although a typical EC curve is unbreakable except by a brute force 
algorithm of order 2^(n/2), a wide variety of special EC curves have 
been discovered that allow faster, much faster, methods of breaking. 
Some of these are so common that any freshly generated curve needs to be 
checked against them to make sure it is a strong curve.


Suppose that the NSA knows some of these that are not known outside the NSA.

Then it could generate a trillion curves, until it hits one that is a 
curve that the NSA can recognize as weak, but that other people cannot 
recognize as weak.


It then makes that curve a standard, and uses the usual state pressures 
to get it included in all widely used software.


Therefore, use Curve25519.  Don't use NIST curves.

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

Re: [cryptography] [Cryptography] RSA equivalent key length/strength

[James A. Donald]

On 2013-09-22 23:01, Peter Gutmann wrote:


You're assuming that someone got passed a suitcase full of cash and that was
it.  Far more likely that RSA got a $10M contract for some government work and
at some point that included a request to make the ECDRBG the default for
insert plausible-sounding reason here.  All quite above board, nothing
terribly suspicious to raise eyebrows.


Possibly, but security agencies do tend to use the suitcase full of cash 
gambit, not to mention the we know where your children live gambit.  
This, however, because done in secret, tends to be even more wasteful 
and expensive that the supposedly above ground government contract.


For a security agency to order a pizza costs ten million dollars.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Fatal flaw in Taiwanese smart card RNG

[James A. Donald]

On 2013-09-17 02:56, Seth David Schoen wrote:


Well, there's a distinction between RNGs that have been maliciously
designed and RNGs that are just extremely poor (or just are
inadequately seeded but their designers or users don't realize this).

It sounds like such extremely poor RNGs are getting used in the wild
quite a bit, and these problems might well be detected by more
systematic and widespread use of these researchers' techniques.  It's
true that a maliciously designed RNG would not be detected this way.
The researchers do emphasize that


Typical design:   Bad randomness seeds a good pseudo random number 
generator - which unintentionally hides the fact that the randomness is 
weak.


Thus the difference between a malicious random number generator, and a 
random number generator where the seeding just is not working right, is 
seldom observable.



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

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

[James A. Donald]

On 2013-09-09 2:26 PM, David Johnston wrote:

On 9/7/2013 6:11 PM, James A. Donald wrote:

On 2013-09-07 9:14 PM, Eugen Leitl wrote:

That's the claimed design, yes.  I see no particular reason to believe
that the hardware in my server implements the design.  I can't even 
test

that the AES whitening does what it is documented to do, because Intel
refused to provide access to the prewhitened input.


On chip whitening is extremely suspicious behavior.  Since the need 
for random numbers is low bandwidth, on chip whitening is a waste of 
silicon.


Despite repeated requests, the decision to do whitening on chip has 
never been explained.




I answered this once before many months ago, the last time you asked.

There is no 'whitener'. It is a CBC-MAC based entropy extractor, as 
per the spec in the current SP800-90B draft. You can call it a 
whitener, but that would risk confusing it with things like the Von 
Neumann or Yuval Peres whiteners, which are a different class of 
algorithm with different constraints.


The reasons for it are:

#1) Maintaining a strong security boundary. We don't want an attacker 
to be able to infer the seed values by exposing them to all sorts of 
classes of attack by letting the values get into the system state 
accessible by the microprocessor SW.


#2) FIPS compliance. Which is more or less #1 restated. It wants stuff 
to happen within a well defined boundary.


#3) Robust engineering. Our goal is to make the lack-of-entropy 
problem go away on intel based products. Reseeding the DRBG 2 million 
times a second is a good way of making it hard to infer the state of 
the DRBG. This is one of several stages of mitigation design, intended 
to make the DRBG robust even if a problem should arise with any one of 
the stages. You can't do that in software. In general, once attackers 
have got a foot in the door of a software system, it is game over.


#4) Software solutions have been a demonstrable failure. At least this 
hardware solution remains robust.


Software solutions are only a failure because software cannot create 
randomness.  Given a supply of colored noise, software can process it 
into white noise, as your on chip software is doing.


You are moving the software solution on chip - where we cannot know 
whether it is a failure or not.


You should have made the raw entropy source available to software, and 
let software do all that stuff.


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

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

[James A. Donald]

On 2013-09-09 3:18 PM, Greg Rose wrote:
I actually hate to point this out, but having access to something that 
looks like a raw entropy source proves nothing.


A genuine hardware noise source will show colored noise, which is very 
hard to simulate in software, and especially hard to simulate at any 
reasonable speed.


If the entropy source is real, it will show its analog characteristics 
leaking into the digital abstraction. The correlations and anti 
correlations between nearby bits will reflect the analog values of the 
circuit, thus no two chips will show quite the same correlations, and 
the correlations will vary with temperature and overclocking. These 
analog variations would be compelling evidence that the entropy source 
is the claimed circuit or something very like the claimed circuit.


Any Intel misconduct would show up in the color of the noise, it being 
very hard to create a digital pseudo noise source that displays subtly 
varying color at high speed, while hardware true random noise sources 
almost unavoidably display subtly varying noise color.)

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

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

[James A. Donald]

On Mon, Sep 9, 2013 at 6:08 AM, Jon Callas j...@callas.org
wrote:
 ... I have to disagree with you. Lots of us have told
 Intel that we really need to see the raw bits, and lots of
 us have gotten informal feedback that we'll see that in a
 future chip.

On 2013-09-10 3:43 AM, coderman wrote:
 i've never seen this stated; it would be great news!

Good cop, bad cop.  Unofficial reassurance is never worth
anything, it is always a prelude to betrayal, always a lie
told with malice and intent to harm,  I am not reporting on
how Intel works, I am reporting on how large bureaucratic
organizations work.

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

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

[James A. Donald]

--
On 2013-09-09 3:18 PM, Greg Rose wrote:
 I actually hate to point this out, but having access to
 something that looks like a raw entropy source proves
 nothing.

On 9/9/2013 5:12 AM, James A. Donald wrote:
 A genuine hardware noise source will show colored noise,
 which is very hard to simulate in software, and especially
 hard to simulate at any reasonable speed.

On 2013-09-10 1:11 AM, David Johnston wrote:
 It's not 'very hard'. Just suppress long strings a bit.

Hard to suppress long strings by an amount that subtly varies
according to temperature and clock speed, and subtly varies
from one chip to the next.  And my reading of the circuit is that
you are also going to have to enhance short strings a bit.

  If the entropy source is real, it will show its analog
  characteristics leaking into the digital abstraction. The
  correlations and anti correlations between nearby bits
  will reflect the analog values of the circuit, thus no
  two chips will show quite the same correlations, and the
  correlations will vary with temperature and overclocking.
  These analog variations would be compelling evidence that
  the entropy source is the claimed circuit or something
  very like the claimed circuit.

 Just because the entropy source is real doesn't mean it's
 feeding the conditioner.

Which is why, if we had direct acess to the entropy source,
no one other than an NSA plant would use the on chip
conditioner.

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

Re: [cryptography] Random number generation influenced, HW RNG

[James A. Donald]

On 2013-09-09 1:54 AM, Thor Lancelot Simon wrote:

On Sun, Sep 08, 2013 at 03:00:39PM +1000, James A. Donald wrote:

On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote:

On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote:

Well, since you personally did this, would you care to explain the
very strange design decision to whiten the numbers on chip, and not
provide direct access to the raw unwhitened output.

You know as soon as anyone complained about this, they turned around
and provided access to the unwhitened output in the next major version
of the same product family, right?

I am not aware of this.  Could you provide further details?

http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed


RDSEED provides the output of the /enhanced/ non-deterministic random 
number generator (ENRNG


Which is enhanced by being whitened.

And therefore makes it just as impossible to tell if the supposed 
randomness is backdoored as RDRAND does.


What we need is the output of the entropy source.

Supposedly we have a circuit that generates fairly random offwhite 
noise. (The entropy source) This is then AES encrypted (the enhanced non 
deterministic number generator), and the enhanced non deterministic 
random number generator then continuously seeds a pseudo random number 
generator, which provides the output of RDRAND


To tell if there is a backdoor or not, we need the output of the entropy 
source, unenhanced.


If the entropy source is real, it will show its analog characteristics 
leaking into the digital abstraction.  The correlations and anti 
correlations between nearby bits will reflect the analog values of the 
circuit, thus no two chips will show quite the same correlations, and 
the correlations will vary with temperature and overclocking.  These 
analog variations would be compelling evidence that the entropy source 
is the something very like the claimed circuit.


Because RDSEED gives us the encrypted output of the entropy source, we 
cannot tell if the entropy source is a real entropy source, or a counter 
encrypted with the NSA's secret key.


Since the whitening is deterministic, it is potentially reversible, but 
Intel does not appear to be releasing sufficient information to reverse it.


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

Re: [cryptography] Random number generation influenced, HW RNG

[James A. Donald]

On 2013-09-08 3:48 AM, David Johnston wrote:
Claiming the NSA colluded with intel to backdoor RdRand is also to 
accuse me personally of having colluded with the NSA in producing a 
subverted design. I did not.


Well, since you personally did this, would you care to explain the very 
strange design decision to whiten the numbers on chip, and not provide 
direct access to the raw unwhitened output.


A decision that even assuming the utmost virtue on the part of the 
designers, leaves open the possibility of malfunctions going undetected.


That is a question a great many people have asked, and we have not 
received any answers.


Access to the raw output would have made it possible to determine that 
the random numbers were in fact generated by the physical process 
described, since it is hard and would cost a lot of silicon to simulate 
the various subtle offwhite characteristics of a well described actual 
physical process.



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

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

[James A. Donald]

On 2013-09-07 9:14 PM, Eugen Leitl wrote:

That's the claimed design, yes.  I see no particular reason to believe
that the hardware in my server implements the design.  I can't even test
that the AES whitening does what it is documented to do, because Intel
refused to provide access to the prewhitened input.


On chip whitening is extremely suspicious behavior.  Since the need for 
random numbers is low bandwidth, on chip whitening is a waste of silicon.


Despite repeated requests, the decision to do whitening on chip has 
never been explained.


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

Re: [cryptography] Random number generation influenced, HW RNG

[James A. Donald]

On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote:

On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote:

Well, since you personally did this, would you care to explain the
very strange design decision to whiten the numbers on chip, and not
provide direct access to the raw unwhitened output.

You know as soon as anyone complained about this, they turned around
and provided access to the unwhitened output in the next major version
of the same product family, right?


I am not aware of this.  Could you provide further details?

And since no one needs high bandwidth true random numbers, why the on 
chip whitening?  Surely there was some internal discussion of this decision?

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

Re: [cryptography] what has the NSA broken?

[James A. Donald]

Most private keys are issued by, not merely certified by, the CAs.

If issued by, not private.  Chances are the controlling authority also 
gets a copy of that private key.


To install your keys on your https server is painful, despite numerous 
people assuring me it is easy, and involves transporting the secret key 
hither and yon, even when done correctly.


And it is never correct to transport secret keys hither and yon.

It would be far easier if installation of an http server /automatically 
generated the private key on the server that the private key was to 
secure/, so as to minimize private key transport, automatically creating 
a self signed certificate, and then you could send off the self signed 
certificate to be made into a CA signed certificate while continuing to 
use the same private key, so that when you set up a server, you never 
have to be aware of the existence of such a thing as a private key, 
merely a certificate.


Also, of course, browsers should not put up horrible scary warnings 
about self signed keys, treating them instead as at worst no worse than 
http, and, at best, taking advantage of key continuity.
It seems to me that the current complicated user hostile system for 
getting servers certified is designed to create and maintain a massive 
security hole, that it would be a lot easier to do things the right way, 
while now we are doing things the wrong way.


From the point of view of the person configuring a server, the public 
key should just be a guid that the server randomly generates to uniquely 
identify itself, the CA certifies the association of this guid with an 
organization and/or domain name, and as for the private key, no one 
should know about that, therefore, no one should ever have to care about 
that or think about that.


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

Re: [cryptography] what has the NSA broken?

[James A. Donald]

On 2013-09-06 11:58 PM, Ralph Holz wrote:

I'd be surprised if a majority of CAs
insisted on generating the key for you.


No one insists, as far as I know.  The problem is that idiocy is 
possible and permissible, not that it is mandatory.



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

Re: [cryptography] no-keyring public

[James A. Donald]

On 2013-08-25 7:58 AM, James A. Donald wrote:

On 2013-08-25 2:30 AM, � wrote:

hi list,

i had an epiphany today, and i wonder if such a thing already exists 
or not.


so the usual thing is to create a key pair, store the private key 
encripted with a password. we automatically get a two factor 
authentication, we have a know and a have. okay, but what if we 
don't want this, and we want our old password only, no keyring approach?


we can do that. how about this? stretch the password with some KDF, 
derive a seed to a PRNG, and use the PRNG to create the the key pair. 
if the algorithm is fixed, it will end up with the same keypair every 
time. voila, no-keyring password-only public key cryptography.


do you see any downsides to that, besides the obvious ones that 
follow from the no-keyring requirement? (slow, weak password.)


has anybody done something like that already? does it have a name?




Attacker applies dictionary attack.

To avoid dictionary attack, use zero knowledge passphrase proof 
(ZKPP)to obtain passphrase authenticated key agreement with a server 
(for which the acronym is PAKE, not PAKA as one might expect)


Server supplies a unique salt, derived from the server's secret and 
the user login, with the user combines with his passprhase


If user has strong passphrase, server cannot guess user's secret key

If user has weak passphrase, server, but not eavesdropper, can 
reconstruct secret key by dictionary attack.

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

Re: [cryptography] urandom vs random

[James A. Donald]

On 2013-08-20 1:31 AM, ianG wrote:
It's a recurring theme -- there doesn't seem to be enough market 
demand for Hardware RNGs.


Every microphone is a hardware RNG

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

Re: [cryptography] urandom vs random

[James A. Donald]

On 2013-08-21 7:33 AM, grarpamp wrote:

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?
___



You cannot test and evaluate a supposedly random number stream. True 
randomness and cryptographically strong pseudo randomness are not 
directly observable qualities.


You have to look at the underlying generation mechanism and deduce 
randomness, or the lack thereof.


If you apply a whitening expander to the source stream 000 
the output stream will look convincingly random, but will be completely 
non random to anyone who knows the whitening expander and knows or 
suspects that the source stream is completely non random

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

[cryptography] Jingle and Otr

[James A. Donald]

Jingle supports voice, video, and text messaging.

OTR is a reasonably user friendly encryption system, or at least less 
user hostile than most, that, unlike skype, does not suffer a central 
point of failure


pidgin supports both jingle and otr, as well as just about everything 
else in the known universe.


Is there any convenient way to communicate by video protected by otr?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Jingle and Otr

[James A. Donald]

On 2013-08-21 12:33 PM, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/20/13 8:31 PM, Natanael wrote:

https://jitsi.org/Documentation/ZrtpFAQ

ZRTP and the GNU ZRTP implementation provide features to
communication programs to setup of secure audio and video session
without additional infrastructure, server programs, registration,
and alike.

While this doesn't state outright that Jitsi uses ZRTP for video
(it does for voice), I believe it does.

Yes, Jitsi uses ZRTP for video.

The Jitsi FAQ https://jitsi.org/Documentation/FAQ says that chat 
sessions are protected by OTR, which implies that nothing else is.


In which case, one is better off using skype, where at least only Skype 
central is ratting you out.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Jingle and Otr

[James A. Donald]

On 2013-08-21 2:00 PM, Natanael wrote:

Well, the point here is that ZRTP for video and voice pretty much is
functionally equivalent to OTR for IM. OTR is designed for messages,
ZRTP is designed for data streams.


Ah yes, I see:

I was thinking of the problem from a text point of view, where 
cryptographically identifying the right target is hard.  In video, not hard.


   *ZRTP] allows the detection of man-in-the-middle (MiTM) attacks by
   displaying a short authentication string (SAS) for the users to read
   and verbally compare over the phone**.* ... But even if the users
   are too lazy to bother with short authentication strings, we still
   get reasonable authentication against a MiTM attack, based on a form
   of key continuity. *It does this by caching some key material to use
   in the next call, to be mixed in with the next call's DH shared
   secret, giving it key continuity properties analogous to Secure
   SHell (SSH)*.

If you know the face of the person you are talking to, you can surely 
tell if the right person is speaking the right SAS, which makes the 
methods used by OTR overkill for video.


Since humans are good at live face recognition, this makes it possible 
to locate the target person by insecure identifiers.



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

Re: [cryptography] urandom vs random

[James A. Donald]

On 2013-08-18 4:11 PM, Ben Laurie wrote:


If I chose to run Linux, I could fix the version I ran. In fact, I 
choose not to run it, so I don't need to.


But if you write software, you don't write it just for your own 
computer, so if you write software for linux, you have to write it for 
the linux that everyone else runs.


Which you cannot fix.


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

Re: [cryptography] Reply to Zooko (in Markdown)

[James A. Donald]

On 2013-08-17 4:04 PM, Jon Callas wrote:

The problems run even deeper than the raw practicality. Twenty-nine years ago this month, in the August 1984 
issue of Communications of the ACM (Vol. 27, No. 8) Ken Thompson's famous Turing Award lecture, 
Reflections on Trusting Trust was published. You can find a facsimile of the magazine article at 
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf and a text-searchable copy on 
Thompson's own site, http://cm.bell-labs.com/who/ken/trust.html.


An attack such as that described by Ken Thompson is extremely brittle, 
narrowly targeted, and subject to rapid bitrot.  It would only be used 
to target universally used and infrequently changing code - operating 
system code.  Therefore, irrelevant for applications.



further, the attack is defeated, and potentially detected, by cross 
compilation, which happens all the time during operating system development.

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

Re: [cryptography] urandom vs random

[James A. Donald]

On 2013-08-17 5:57 PM, Peter Gutmann wrote:

Nico Williams n...@cryptonector.com writes:


It might be useful to think of what a good API would be.

The problem isn't the API, it's the fact that you've got two mutually
exclusive requirements, the security geeks want the (P)RNG to block until
enough entropy is available, everyone else wants execution to continue without
being blocked.  In other words a failure of security is preferred to a failure
of functionality.  Until you resolve that conflict, no API (re)design is going
to help you.


The security geeks are the only people who want to use these.  If on 
some systems urandom is fixed to not block at startup, cannot use it 
portably.



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

Re: [cryptography] urandom vs random

[James A. Donald]

On 2013-08-17 10:12 PM, Ben Laurie wrote:


What external crypto can you not fix? Windows? Then don't use 
Windows. You can fix any crypto in Linux or FreeBSD.


No you cannot.



So what? BSD's definition is superior. Linux should fix their RNG. Or 
these people who you think should implement their own should. Or they 
could just switch to BSD.


That it does not, implicitly admits that you, Ben Laurie, cannot fix linux.

We want that all implementations of /dev/random and /dev/urandom behave 
the same, and that they behave correctly on all machines.  We don't have 
that.


Hence the need for each implementer to reinvent the wheel.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] urandom vs random

[James A. Donald]

At startup, likely to be short of entropy.

Actual behavior, and even existence, of /dev/random and /dev/urandom 
varies substantially from one implementation to another.


If /dev/random blocks when short of entropy, then likely to block at 
startup, which is good.  Services that need entropy do not need to start 
immediately.  If they take a while to come up, no big deal.


If /dev/urandom seeded at startup, and then seeded no further, bad, but 
not very bad.


If /dev/urandom seeded at startup from /dev/random, then should block at 
startup.


If /dev/urandom never blocks, bad.  Should block at startup waiting to 
receive 160 bits from /dev/random, and never block again.


Ron Peterson reports /dev/random not very random 
http://bytes.com/topic/c/answers/219952-dev-urandom-vs-dev-random









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

Re: [cryptography] urandom vs random

[James A. Donald]

On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com 
wrote:

If /dev/urandom seeded at startup, and then seeded no further, bad, but not
very bad.

If /dev/urandom seeded at startup from /dev/random, then should block at
startup.

If /dev/urandom never blocks, bad.  Should block at startup waiting to
receive 160 bits from /dev/random, and never block again.


On 2013-08-17 12:33 PM, shawn wilson wrote:

I don't follow this - I understand why lack of entropy should block
urandom but, why shouldn't it block on a running system that
low_bound?


Once  /dev/urandom has 160bits of true randomness, can generate 
cryptographically strong pseudo randomness for an unenumerably long time.

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

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

[James A. Donald]

On 2013-08-14 6:10 AM, Nico Williams wrote:

  - it's really not easy to defeat the PRISMs.  the problem is
*political* more than technological.


For a human to read all communications would be an impossible burden.

Instead, apply the following algorithm.  Identify people of interest.  
Read communications between persons of interest.  If several people of 
interest talk to Bob, then Bob may well also a person of interest. 
/Then/ read their communications.  If significant, add Bob to the list 
of people of interest.


Looking at communication patterns, Identify the more central nodes among 
people of interest.  Make a special effort to crack the communications 
of the most central nodes.


The technological counter to this is the cypherpunks remailers, which 
are unfortunately user hostile, especially when used with a permanent 
identity.





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

Re: [cryptography] Grover's Algo Beaten?

[James A. Donald]

On 2013-07-28 1:29 PM, Russell Leidich wrote:

Is this to be taken seriously...

Massachusetts Institute of Technology professor Seth Lloyd claims to 
have developed a quantum search algo which can search 2^N (presumably 
unsorted) records in O(N) time. (This is the subtext of this mundane 
article about VC funding for search engines.)


http://www.eetimes.com/document.asp?doc_id=1319059
http://www.amazon.com/books/dp/1400033861

Reading between the lines, it sounds like the input is a binary 
pattern, and the output is a record number where said pattern is 
found, assuming that it exists in the database. (If it exists in 
multiple records, then each of those matches will be returned with 
essentially equal probability.)


To the quantum computing notice, this invention is unsurprising. After 
all, N qubits in superposition assume 2^N states across multiverses, 
which obviously means that shortly after the computer starts up, it 
will already have found the desired record if it exists.


But methinks this is all wrong. Grover's algo can only search 2^N 
unsorted records in O(2^(0.5N)) time. If I'm not mistaken, this 
derives from the difficulty of amplifying the correct result, in the 
presence of large numbers of near matches. For its part, DWave's 
operating manual goes into detail about this issue, involving 
Maxwell-Boltzmann energy distributions, providing practical evidence 
of this severe acceleration impediment.




DWave uses a different algorithm.  You might say that they create a 
hamiltonian whose ground state corresponds to the solution.


Loyd proposes to create a hamiltonian that moves  to a non ground state 
that corresponds to the solution.


DWave's algorithm is based on what their hardware can actually do - 
DWave is not a general purpose quantum computer, far from it.  Loyd is 
writing programs for a hypothetical general purpose quantum computer



___
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

[James A. Donald]

On 2013-07-22 9:01 AM, Randall Webmail wrote:


[SNIP]
To derive a DES OTA key, an attacker starts by sending a binary SMS to 
a target device. The SIM does not execute the improperly signed OTA 
command, but does in many cases respond to the attacker with an error 
code carrying a cryptographic signature, once again sent over binary 
SMS. A rainbow table resolves this plaintext-signature tuple to a 
56-bit DES key within two minutes on a standard computer.


*Deploying SIM malware.* The cracked DES key enables an attacker to 
send properly signed binary SMS, which download Java applets onto the 
SIM. Applets are allowed to send SMS, change voicemail numbers, and 
query the phone location, among many other predefined functions. These 
capabilities alone provide plenty of potential for abuse. [SNIP]


https://srlabs.de/rooting-sim-cards/



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.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger

[James A. Donald]

On 2013-07-13 12:20 AM, Eugen Leitl wrote:
It's worth noting that the maintainer of record (me) for the Linux RNG 
quit the project about two years ago precisely because Linus decided 
to include a patch from Intel to allow their unauditable RdRand to 
bypass the entropy pool over my strenuous objections.


Is there a plausible rationale for bypassing the entropy pool?

How unauditable is RdRand?

Is RdRand unauditable because it uses magic instructions that do 
unknowable things?  Is it designed to actively resist audit?  Has Intel 
gone out of its way to prevent you from knowing how good their true 
random generation is?


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

Re: [cryptography] DeCryptocat

[James A. Donald]

On 2013-07-05 6:34 AM, Silas Cutler wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, long time lurker, first time poster.  Hate my first post to be 
a negative one. 


http://tobtu.com/decryptocat.php

Brief
DecryptoCat v0.1 cracks the ECC public keys generated by Cryptocat 
https://crypto.cat/ versions 1.1.147 through 2.0.41. Cryptocat 
version 2.0.42 was released Feb 19, 2013 which increased the key space 
from 2^54.15 to 2^106.3. Decryptocat takes advantage of a 
meet-in-the-middle attack called baby-step giant-step you can 
effectively square root the key space. So 2^54.15 turns into 2^27.08 
and 2^106.3 to 2^53.15. For Cryptocat versions before 2.0.42, doing a 
split of 2*10^9 and 10^7 it takes about a day to calculate data needed 
to crack any key in few minutes.


tl;dr -If you used Cryptocat from October 17th, 2011 to June 15th, 
2013 assume your messages were compromised. Also if you or the person 
you are talking to has a version from that time span, then assume your 
messages are being compromised.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
randombit.net/mailman/listinfo/cryptography 


106 bits is still far too small.  Seems to me that they only increased 
it as needed to defeat DecryptoCat, not as needed to defeat an NSA farm 
running dedicated special purpose hardware.


Why not use an elliptic curve whose points are, in compressed form, 
about 256 bits, which is the size I chose for Crypto Kong, many, many 
years ago, when computers were far less powerful.  I chose that after 
looking at various cracking efforts as the minimum size that I was 
pretty sure that the NSA could not beat, then or in the reasonably near 
future.


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

Re: [cryptography] DeCryptocat

[James A. Donald]

On 2013-07-05 7:18 AM, Michael Rogers wrote:
The choice of curve wasn't the problem - they were using Curve25519 
but messing up the random number generation.


Ah, I see.

They have company.


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

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

[James A. Donald]

On 2013-07-04 2:11 AM, Wasabee wrote:

On 03/07/2013 13:31, Michael Rogers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/13 13:26, danimoth wrote:

Not directly related to remailer, but what about dc nets [1] ?

[1] The Dining Cryptographers Problem:
 Unconditional Sender and Recipient Untraceability (David Chaum)

DC nets have two major drawbacks: they don't scale, and any participant
can anonymously jam the channel. Dissent is a recent system that aims to
address both drawbacks:
https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet 



is it really feasible to get good latency/bandwith with such system? 
it seems users need to transmit packets at the same time; so it seems 
the latency and bandwidth is a bottleneck because everyone must wait 
for the users with highest latency and lowest bandwidth? Or is there a 
scheduling mechanism involved (which would eat up usable bandwidth)?


Also, how much trust is put on servers compared to Tor? At first 
sight, it seems that the compromise of one server will compromise all 
clients connected to this server since servers knows all their shared 
secret.


It suffices that one server is not controlled by your adversary, even if 
all the others are NSA plants, even if the server you are using is an 
NSA plant.


However, a single evil server can jam the channel, so have to identify 
and throw out actively disruptive servers.


Effectively, the servers form a DC net, and client anonymity is layered 
on top of that.

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

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

[James A. Donald]

On 2013-07-01 9:50 PM, Ben Laurie wrote:

On 1 July 2013 12:32, Tom Ritter t...@ritter.vg wrote:

On 1 July 2013 05:04, Ben Laurie b...@links.org wrote:

On 1 July 2013 01:55, Jacob Appelbaum ja...@appelbaum.net wrote:

So then - what do you suggest to someone who wants to leak a document to
a press agency that has a GlobaLeaks interface?

I would suggest: don't use GlobalLeaks, use anonymous remailers.
Bottom line: Tor is weak against powerful adversaries because it is
low latency. High latency mixes are a lot safer.

GlobalLeaks should have an email API, IMO.

Having looked a lot at the current remailer network, and a bit at
GlobaLeaks - I'm going to wade in and disagree here. (Although this
thread has gotten woefully off topic after I've bumped it. =/)  Ben: I
love mix networks. I've been learning everything I can about them, and
have been researching them voraciously for a couple years.[0]  But IMO
the theoretical gains of high latency *today* are weaker than the
actual gains of low latency *today*.

Virtually all remailer use is Mixmaster, not Mixminion.  If you want
to use anything but a CLI on Linux - you're talking Mixmaster.  So I'm
assuming you mean that.  Mixmaster uses a very, very recognizable SMTP
envelope, that often goes out with no TLS, let alone no PFS.  There's
also precious few people actually using it.  And finally, if you look
at the public attacks on remailers (the unfortunate bombing threats of
last summer) and Tor (the Jeremy Hammond case) - you see that Feds are
willing to go on fishing expeditions for remailers, but less so Tor.
Tor was traffic confirmation, Remailers was fishing.[1]

Compare to GlobaLeaks.  Tor Hidden Service, Tor network.  The two
biggest threats are Traffic Correlation and the recent attacks on
Hidden Services.

Assume a Globally Passive Adversary logging all SMTP envelopes
(because... they are. So don't assume, know.).  Now assume a leak
arrives over email.  Light up all the nodes who sent a message via
Mixmaster within a couple days, and you'll get at most, a couple
hundred.  Now dim all the lights who've never sent a mixmaster message
before.  You'll get a couple.  That's enough to investigate them all
using traditional methods.

Now you *do* have to assume a GPA who's logging all Tor traffic.  It's
possible.  Some would even say it's probable.  But we've seen no
evidence. Do the same light-up.  You get a hundreds if not thousands
of nodes.  Too many to investigate traditionally.  And to do Traffic
Confirmation, you need to identify the Hidden Service.  And there's
the issue that it's not trivial to do traffic confirmation.

Oh and there's also the little problem of sending anything over 10,236
bytes via Mixmaster splits the message into multiple messages that all
emanate from your machine which makes it wildly probable some won't
arrive, and also drastically makes you stand out the crazy person
who's trying to send anything other than text through Mixmaster.

I'm not saying GlobaLeaks+Tor is safe.  I'm saying I think our current
remailer network is wildly unsafe.  (Now what I think about fixing
it... that's a whole other story, for a whole other time.)

You are probably right - remailers are not what they used to be.

The more interesting point is high vs low latency. I really like the
idea of having a high-latency option in Tor. It would still need to
have a lot of users to actually be useful, though. But it seems there
are various protocols that would be ore high-latency-friendly than
HTTP - SMTP, of course, and XMPP spring to mind.


One solution would be to have an anonymizing remailer inside  tor as a 
hidden service.  You send emails to that service.  A random time later, 
they are sent to their destination.







-tom

[1] https://crypto.is/blog
http://defcon.org/html/defcon-21/dc-21-speakers.html#Ritter
[1] If you don't like my last argument, fine, ignore it, and work with
the others.

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



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

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

[James A. Donald]

On 2013-07-02 8:47 AM, Nico Williams wrote:

On Mon, Jul 1, 2013 at 4:57 PM, grarpamp grarp...@gmail.com wrote:

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.

I'd love to see proposals for how to criminal prosecutions by the
public would work.


Until 1930 or so, in California, pretty much all criminal prosecutions 
were by the public.  I would suppose the laws are still in place, just 
not applied.


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

Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)

[James A. Donald]

On 2013-06-30 5:13 PM, Danilo Gligoroski wrote:

This was expected.
As Skype definitely ruined its reputation as free end-to-end application for
secure communication, other products are taking their chances.

Agencies showing sudden interest in encrypted comm ---
http://gcn.com/blogs/cybereye/2013/06/agencies-sudden-interest-encrypted-com
m.aspx




Silent Circle expects end users to manage their own keys, which is of 
course the only way for end users to be genuinely secure. Everything 
else is snake oil, or rapidly turns into snake oil in practice.  (Yes, 
Cryptocat,  I am looking at you)


However, everyone has found it hard to enable end users to manage keys.  
User interface varies from hostile, to unbearably hostile.


Silent Circle publish end users public keys, which would seem to create 
the potential for a man in the middle attack.


I would like to see a review and evaluation of Silent Circle's key 
management.

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

Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)

[James A. Donald]

On 2013-07-01 8:55 AM, Nadim Kobeissi wrote:

On 2013-06-30, at 3:44 AM, James A. Donald jam...@echeque.com wrote:


On 2013-06-30 5:13 PM, Danilo Gligoroski wrote:

This was expected.
As Skype definitely ruined its reputation as free end-to-end application for
secure communication, other products are taking their chances.

Agencies showing sudden interest in encrypted comm ---
http://gcn.com/blogs/cybereye/2013/06/agencies-sudden-interest-encrypted-com
m.aspx

Silent Circle expects end users to manage their own keys, which is of 
course the only way for end users to be genuinely secure. Everything 
else is snake oil, or rapidly turns into snake oil in practice. (Yes, 
Cryptocat, I am looking at you) 
You seem to be implying that Cryptocat does not manage keys on the 
end-user side. This is false � Cryptocat users do manage their own 
keys on the client side, in fact.



According to the paper, there are no long term public and private keys.  
ID is therefore wholly username and password


   Cryptocat does not currently store long-term key pairs (see x 9.2),
   need to be generated, along with DSA pa-rameters, each time
   the application is launched

Which of course does not make cryptocat inherently insecure, or fatally 
flawed, but nonetheless, does not provide the security that would come 
from users managing their own keys, if ever we managed to provide an 
interface where users successfully managed their own keys without 
screwing up.





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

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

[James A. Donald]

On 2013-06-30 10:21 AM, Natanael wrote:



Of course there's that whole 'almost none of our tools are usable'
problem.



That problem needs fixing first.  Only then will our enemies start 
bothering with pattern recognition and such.


Right now, the most trivial precautions result in you not being traced 
and observed.  They only bother with the low hanging fruit.


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

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

[James A. Donald]

The biggest Tor vulnerability is that governments and large criminal 
organizations (but I repeat myself) can use their influence over a CA to 
perform a man in the middle attack.


I don't think they are doing this (as I said, they only bother with the 
low hanging fruit) but they could.


Is there a tool that detects changes of CA?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Cryptocat: Adopting Accessibility and Ease of Use as Security Properties

[James A. Donald]

On 2013-06-25 1:02 AM, Nadim Kobeissi wrote:

Today, with Cryptocat nearing 65,000 regular users, the Cryptocat project 
releases �Cryptocat: Adopting Accessibility and Ease of Use as Security 
Properties,� a working draft which brings together the past year of Cryptocat 
research and development.


Where does cryptocat keep the secret keys, and how does the user 
perceive them?  How are they represented to the user?


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

Re: [cryptography] 100 Gbps line rate encryption

[James A. Donald]

On 2013-06-23 6:47 AM, Peter Maxwell wrote:



I think Bernstein's Salsa20 is faster and significantly more secure 
than RC4, whether you'll be able to design hardware to run at 
line-speed is somewhat more questionable though (would be interested 
to know if it's possible right enough).


I would be surprised if it is faster.


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

Re: [cryptography] CTR mode limit cycle length

[James A. Donald]

On 2013-06-13 12:31 PM, Russell Leidich wrote:
Not to detract from the important discussion of how best to use AES 
CTR mode, but I have a more basic question...


I can certainly understand why the discussion of CTR mode is 
considered to be boring. I assume that anyone can easily verify that 
testing trillions of different 128-bit counter values, even in 
incremental sequence, produces radically different xor masks, given a 
reasonable IV.


But what's the probability of 2 xor masks colliding? Is this just 
assumed to be random, i.e. compatible with a birthday attack?


If it was not random there would be equivalent attacks on all other modes.

I am seeing a lot of people imagining all sorts of problems with ctr 
happening under certain circumstances, when, given those circumstances, 
there would be equivalent problems with all other modes.


This is the bicycle shed effect.

A committee has to a discuss a ten million dollar auditorium and a five 
hundred dollar bicycle shed.  The auditorium goes through in three 
minutes, because no one understands the potential problems with the 
auditorium, whereas the bicycle shed bogs down the committee for three 
months.


For example someone pointed out that ctr is problematic because you 
don't necessarily have access to true randomness or non repeating pseudo 
randomness.


Well guess what?  Every other mode needs randomness also.

Every other mode needs authentication also.




Has anyone done anything like a limit median iteration count before 
repetition (LMICBR) test or scintillating entropy test? (These are 
described in detail on my blogs.) The former test, which could 
actually be performed in useful fashion on a 128-bit space using 
existing computer power, would likely throw up warning signs if the 
cycle were too short. The latter test would potentially shrink the 
upper bound complexity estimate for differential (i.e. interblock) 
cryptanalysis.


So if, let's say, 2 in every 100 xor masks collide, then I need only 
store 100 encrypted blocks in order to have a good chance of finding 
of a matching pair (or n-tuple) of xor masks, thereby facilitating 
statistical cracking methods. Obviously 100 is too small. So what is 
the actual number, for a given counter width?


Personally, I'd prefer to rely on the predictable limit cycles of 
Karacell 3 (but then, I'm biased). But I'm quite open to a 
demonstration or whitepaper showing that CTR limit cycles are also 
predictable and usefully long. Or maybe I've just misunderstood how 
CTR works. Anyone?




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


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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-26 2:13 AM, Eric S Johnson wrote:


Sauer: We answer to this question: We provide a safe communication 
option available. I will not tell you whether we can listen to it or not.


In other words, no evidence there, either.



Oh come on.  We will not tell you tells us.


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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-23 3:28 AM, Florian Weimer wrote:

* Adam Back:


If you want to claim otherwise we're gonna need some evidence.

https://login.skype.com/account/password-reset-request

This is impossible to implement with any real end-to-end security.


Skype's claim was that it was end to end, except for the possibility of 
man in the middle attack by Skype, and only by Skype.



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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-22 5:00 PM, yersinia wrote:

Sorry for the top posting.

Many company are using private social network these days. As usual
someone internal to the organization has the right to record and sniff
also the private traffic. Don't like ? Well, you can always use
services as scrumbls. Perhaps not so secure from a nsa wiretap but
sufficient in most case.


Scrumbls?

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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

  Cops just don't put that much work in.

On 2013-05-22 5:41 PM, Jacob Appelbaum wrote:
 Yes, yes they do:

 
http://www.scmagazine.com/finfisher-command-and-control-hubs-turn-up-in-11-new-countries/article/291252/


That governments attempt to spy on people is not evidence that they any 
good at it.


If they were half way competent, it would not be possible to detect 
these hubs.


 While I generally understand your arguments, I think you 
underestimate the capabilities of even local police officers.

 There are point and click tools, custom tools and everything in between.

Local police can no more do this stuff than your mother can, and the FBI 
is not a whole lot better.


Consider for example, the boston bombing.  Interested parties threw away 
Tsarnaev's laptop, indicating he had been doing interesting things on 
the internet.  Despite the fact that the FBI had been told by the 
Russian intelligence service Tsarnaev was a terrorist, they had failed 
to collect any interesting internet communications.



Customized solutions are the standard operating procedure. I encourage
you to read this:

   http://www.gpo.gov/fdsys/pkg/CHRG-112hhrg64581/html/CHRG-112hhrg64581.htm



Upon reading it, I find the unsurprising information:  Simply stated, 
the technical capabilities of law enforcement agencies have not kept 
pace with the dazzling array of new communication devices and other 
technologies that are now widely available in the marketplace.


This tells me that not that the police are super terrific hackers who 
produced customized malware for each person's computer, but that they 
are your mother.





===

Ms. Caproni. Thank you for that question. There will always be
criminals, terrorists, and spies who use very sophisticated means of
communications that are going to create very specific problems for law
enforcement. We understand that there are times when you need to design
an individual solution for an individual target, and that is what
those targets present.
 We are looking for a better solution for most of our
targets, and the reality is, I think, sometimes we want to
think that criminals are a lot smarter than they really are.
Criminals tend to be somewhat lazy, and a lot of times, they
will resort to what is easy.
 And so, long as we have a solution that will get us the
bulk of our targets, the bulk of criminals, the bulk of
terrorists, the bulk of spies, we will be ahead of the game. We
can't have individual--have to design individualized solutions
as though they were a very sophisticated target who was self-
encrypting and putting a very difficult encryption algorithm on
for every target we confront because not every target is using
such sophisticated communications.


This tells us that they would like to have customized solutions, that 
they aspire to have customized solutions, but that instead of customized 
solutions they rely on Google and Microsoft vacuuming everything up and 
handing it to them on a platter tied up with a pink ribbon.

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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-22 4:20 AM, Benjamin Kreuter wrote:

On Tue, 21 May 2013 14:17:02 +1000
James A. Donald jam...@echeque.com wrote:


Police install malware by black bagging, and by the same methods as
botnets.  Both methods are noticeable.

I do not think the following scenario is terribly far-fetched:

Suppose the police want to target a grad student in a CS department at
a major university.  The police enter the server room, insert some
malware into the student's research group's git repository, and waits
for the student to merge the changes.  The next time the student runs
whatever code she is working on, the malware will be installed; the
malware then installs a keystroke logger, enables the microphone, etc.
The malware can be even more secretive, only activating on a specific
computer (the target's) or perhaps the police could modify the software
on the server to only send the malware to the target.

Now, let's change this somewhat.  Instead of sneaking into a server
room (or presenting the school with a court order), the police
compromise another grad student's computer, and simply commit their
malware to the group's repository (do you think researchers actually
read commit logs, when they have a deadline in a few days?).


This presupposes custom malware written for the specific target.

Highly customized spearphish attacks are unlikely to be detected, but 
require a lot of smarts per attack.  Government does not display 
evidence of a lot of smarts.


Government employees are seldom the sharpest blade in the box.

They use a standard package written by a private contractor, and use it 
over and over again, and use it badly and crudely.   And that private 
contractor is not going to let them use source code, because it would 
leak, and because they would no more know what to do with source code 
that your mother would.


A more likely attack is spearphishing - standard malware with an attack 
vector customized to the individual but off the shelf script kiddy code 
- social, rather than code, customization.  And even that is a stretch.  
Cops just don't put that much work in.





Now suppose instead of the police, it is a foreign government trying to
get secret research data.  Maybe instead of targeting one research
group, they just target, say, anyone who keeps Matlab source code in a
git repository.


By Matlab source code, you presumably mean source code written to be 
interpreted by Matlab.


How many people in government employment can write and understand Matlab 
source code?  And if they targeted everyone that is a lot of people.  
Someone is going to notice.


Now if someone is working on a missile, /him/ they might well target - 
but he is not going to have his matlab source code on a public repository.


If you are targeting everyone, in the hope of catching a few big fish, 
then you are going to do what the botnet operators do, and will be 
detected the way botnet operators are detected.



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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

James A. Donald:
No one on my buddy list has been taken over, or if they have, they 
took care of it before I noticed. 


On 2013-05-21 10:55 AM, Jacob Appelbaum wrote:


That is - how would they notice and if they were being logged, how would
*you* notice on your end?


I would notice, because they would spam me, this being the primary 
income source and reproductive method for botnets.



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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-21 3:08 AM, Mark Seiden wrote:

(i know that at least jake and ian understand all the nuances here, probably 
better than me.)

bus still, i would like you to consider, for a moment, this question:

suppose there were a service that intentionally wanted to protect recipients of 
communications
from malicious traffic?   when i was at $big_provider, i spent an awful lot of 
time and energy
communicating with colleagues and sharing threat intelligence about bad guys.


Gmail is very efficient at filtering out malicious traffic.  It also 
spies on all its customers and keeps all their mail in the clear forever.


For this reason I use mail services that perform absolutely no 
filtering, and do my own filtering.


If I get filtered, I want to know it.  Furtive filtering is a hostile act.


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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-21 4:50 AM, Mark Seiden wrote:

you can advise whatever you fancy, but skype, google, microsoft are unlikely
to agree to any such thing unless your client is a Really Big company who
pays them a lot of money.  and why should they even bother their lawyers?
pretty much, their service Is What it Is, take it or leave it.


If, however, they don't tell you what their service is ...?

If, out of the kindness of their hearts, they decide to check out all 
your urls /without telling you/.


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

Re: [cryptography] skype backdoor confirmation

[James A. Donald]

On 2013-05-21 12:41 PM, Jacob Appelbaum wrote:

James A. Donald:

James A. Donald:

No one on my buddy list has been taken over, or if they have, they
took care of it before I noticed.

On 2013-05-21 10:55 AM, Jacob Appelbaum wrote:


That is - how would they notice and if they were being logged, how would
*you* notice on your end?

I would notice, because they would spam me, this being the primary
income source and reproductive method for botnets.

You're not distinguishing between the classes of attacker that exist
here; they are not all the same. Police malware only spreads, for
example, when it needs coverage.


Police install malware by black bagging, and by the same methods as 
botnets.  Both methods are noticeable.



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

Re: [cryptography] Skype backdoor confirmation

[James A. Donald]

Obviously a secret is no secret the person sending it is not on your 
buddy list.


Conversely, it should not be possible to inspect messages if the person 
sending it is on your buddy list.

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

Re: [cryptography] ICIJ's project - comment on cryptography tools

[James A. Donald]

On 2013-04-05 10:47 AM, James A. Donald wrote:


How does it work?  Is it really secure, and if it is, how did they 
manage a not one click for security user interface?


Already answered by others on this list.  Not secure, apple can MIM it.

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

Re: [cryptography] Here's What Law Enforcement Can Recover From A Seized iPhone

[James A. Donald]

On 2013-03-29 8:23 AM, Jeffrey Goldberg wrote:

I suspect Apple has the methods/processes to provide it.

I have no more evidence than you do, but my guess is that they don't, for
the simple reason that if they did that fact would leak out. Secret
conspiracies (and that's what it would take) grow less plausible
as a function of the number of people who have to be in on it.


Real secret conspiracy:  Small enough to fit around a coffee table.

Semi secret conspiracy.  Big enough to exercise substantial power, 
powerful enough to say ha ha, you must be crazy, also racist, pawn of 
big oil, Nazi whenever anything leaks out.


Looking back at the early twentieth century, we find an ample supply of 
secret conspiracies which must have hundreds of thousands of people in 
the know.


I could mention two rather famous ones, but this would divert the list 
off topic because three people with ten sock puppets each would then 
post a bunch of messages saying ha ha, you must be crazy





(Furthermore I suspect that implausibility rises super-linearly with
the number of people in on a conspiracy.)


I think there's much more to it than a simple brute force.

We know that those brute force techniques exist (there are several vendors
of forensic recovery tools), and we've got very good reasons to believe
that only a small portion of users go beyond the default 4 digit passcode.
In case of LEAs, they can easily hold on to the phones for the 20 minutes
(on average) it takes to brute force them.

So I don't see why you suspect that there is some other way that only
Apple (or other relevant vendor) and the police know about.

Cheers,

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



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

Re: [cryptography] Here's What Law Enforcement Can Recover From A Seized iPhone

[James A. Donald]

On 2013-03-29 10:47 AM, Nico Williams wrote:

   There is zero chance Apple would be backdooring anything for profit


They might, however, and very likely are, backdooring everything to 
avoid getting their faces broken in with rifle butts.



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

Re: [cryptography] New mailing list for crypto politics/non-tech (Was: Cypherpunks mailing list)

[James A. Donald]

On 2013-03-26 6:21 AM, Jack Lloyd wrote:

I just created a new mailman list
https://lists.randombit.net/mailman/listinfo/cryptopolitics
as a venue for discussions that would normally go to cypherpunks but
hasn't because of the name or spam or whatever reason, and which
are off topic for this list so haven't happened here.


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



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

Re: [cryptography] why did OTR succeed in IM?

[James A. Donald]

On 2013-03-24 3:25 AM, Jon Callas wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Mar 23, 2013, at 6:36 AM, Ben Laurie b...@links.org wrote:


On 23 March 2013 09:25, ianG i...@iang.org wrote:

Someone on another list asked an interesting question:

 Why did OTR succeed in IM systems, where OpenPGP and x.509 did not?

Because Adium built it in?


Yeah. And it just worked.



The hard part of cryptography is always UI.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Iranian Cryptography Vendors

[James A. Donald]

On 2013-03-24 6:28 AM, Ethan Heilman wrote:


Does anyone know where I would be able to find information on what 
cryptographic hardware is currently used by Islamic Republic's 
military and diplomatic organizations? �What vendors they are using 
and what elements of the Iranian government use�foreign�produced 
hardware?�


Presumably anyone who knows that would be located in Iran, and thus 
would surely die if he said that.





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

Re: [cryptography] Keyspace: client-side encryption for key/value stores

[James A. Donald]

On 2013-03-21 5:59 PM, ianG wrote:

On 21/03/13 09:52 AM, Tony Arcieri wrote:


A question about crypto-capabilities is: how do you share them securely?


Using a crypto-capability for secure sharing.  Which leads to a 
boot-strapping problem, of course, but that's part of the fun.


A partial answer from capabilities is found in YURLs which are URLs 
that can't be futzed with by an attacker.  But this still doesn't 
solve the issue of who you send them too...


The high-level helicopter answer is that you bootstrap relationships 
into key exchanges [0], and the hidden assumption here is that you 
have relationships of some form, which means you are now in 
application space -- the market area -- not in systems space.


Or to say the same thing in different words, UI is the hard part of 
crypto, and usually the place where the holes are.


Zooko's triangle is a system level description of a user interface.


In terms of server - user path, the authentication  finding 
mechanism is generally interrelated.  You typically need to start from 
some well known and self-authenticating mechanism which is sometimes 
called a root.


Otherwise known as a single point of failure.

Let us imagine that browsers supported yurls, and that links in 
advertisements and business pages were usually yurls, with the result 
that your bookmarks were usually yurls.


And, let us imagine that email and im addresses were also yurls, and 
usually to be found in web pages themselves secured by yurls, with the 
result that the from address on email was unforgeable, that a from 
address was also a link to the one true home page corresponding to that 
email address.


Then any web page identified by yurl and containing yurls would have the 
functionality of a certificate, rendering certificates as such 
irrelevant.  The entire web would largely consist of certificates, and 
search engines would be certificate servers.


The downside would be that secure email addresses and yurls would be 
impossible to communicate over the phone, or in non web advertisements, 
thus people would tend to default to insecure mode, and could thus 
easily be suckered into using insecure mode


To leverage from insecure mode to secure mode, one needs a preshared 
secret, which only the highly motivated will bother with.

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

Re: [cryptography] Announcing a new JVM crypto library

[James A. Donald]

On 2013-03-17 1:37 PM, Will wrote:

Hello,

I've released a new native OSS crypto library for the JVM that uses
AES-NI, PCLMUL, and RDRAND instructions available on recent x86-64
CPUs:

   https://github.com/wg/crypto

It supports AES in CBC, CTR, and GCM modes with optional
authentication, secure random number generation (RDRAND, Ivy Bridge+
CPUs only), and constant-time byte array comparison. I believe the API
is simple and less error prone than the JCE's. However it is designed
as a low level library and requires the user to correctly assemble the
provided primitives.

This is just a hobby project and I am not a cryptographer. I have
however placed an emphasis on testing and it passes all publicly
available NIST AESAVS tests. The underlying AES implementation is
hardware, and the driver code is OSS from Intel and the OpenBSD
project. The GCM wrapper of CTR and GMAC, RDRAND driver, and other
utilities were written by me.


Doubtless I am not looking in the right place, but I do not see the api 
for RDRAND - or indeed the api for anything.


The documentation for Rdrand appears to be:

 Secure random bytes (requires CPU supporting RDRAND):

Crypto.bytes(iv, len)

Which is less than helpful.


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

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 4:41 AM, StealthMonger wrote:

What's wrong with the following simple idea:

1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to Accept No Substitutes.

3.  Merchant authentication of Customer: Merchants don't deal with
people.  They deal with keys.  It's the key that has the purchasing
power, not some person.  Nobody has the illusion that correlation
between key and person is any stronger than that person's security
habits.

4.  Etc.



Let us suppose we have urls that contain public keys, or hashes of them, 
or shared secrets, and let us suppose that clients and servers know how 
to handle them:  That the client will insist that the server proves 
knowledge of the corresponding secret key, or knowledge of the shared 
secret, without spilling the shared secret to all and sundry.


Can you implement your above design while hiding the keys in urls, 
rather than inflicting them on the suffering user?

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

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

James A. Donald jam...@echeque.com writes:

The key, and the hash of the key, is a long string of random
gibberish.  It should not be visible to end users.  Experience
demonstrates that showing it repels 99% of end users.

On 2013-03-06 9:33 PM, StealthMonger wrote:


Merchant includes its telephone number in every advertisement and 
repeatedly admonishes prospects to call.


That is a short string of gibberish.

Your only argument is that the key ID is longer or more random.


Exactly so.

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

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 1:18 AM, Jeffrey Walton wrote:

That's Patient 0. Its the key distribution problem. Its the cause of
all the troubles.

Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
Convergence, {Certificate|Public Key} Pinning, Key Continuity, etc are
all band-aides for the first patient.


Wrong phrase.  You seldom want to distribute keys.  You want to 
distribute information about public keys.


Key distribution and key management should follow existing practice with 
managing non memorable email addresses, urls and guids, which 
approximates Zooko's triangle

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

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 4:41 AM, StealthMonger wrote:

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to Accept No Substitutes.


The key, and the hash of the key, is a long string of random gibberish.  
It should not be visible to end users.  Experience demonstrates that 
showing it repels 99% of end users.



We have to do all the things you describe, without the end user ever 
seeing the key or the hash of the key.



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