Ron Garret | 25 May 17:25 2016

Stealthy analog trojans

Coming soon to a microprocessor near you

http://static1.1.sqspcdn.com/static/f/543048/26931843/1464016046717/A2_SP_2016.pdf?token=Sqki%2BUKuhrHYxCqc2HU9B1dlHEQ%3D
grarpamp | 18 May 08:38 2016
Picon

RNG Breakthrough: Explicit Two-Source Extractors and Resilient Functions

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

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

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

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

Our explicit two-source extractor directly implies an explicit
construction of a 2(loglogN)O(1)-Ramsey graph over N vertices,
improving bounds obtained by Barak et al. and matching independent
work by Cohen.
_______________________________________________
(Continue reading)

Mansour Moufid | 11 May 05:35 2016
Picon

Open Whisper Systems intellectual property dispute

I just heard very unfortunate news about some intellectual property
dispute between Open Whisper Systems and another company.

I won't link to it here, I don't think it would do any good.

It's a strange story.  The double ratchet protocol specification is
dedicated to the public domain, the reference implementation is open
source, and the other implementation is in a different programming
language.  So what could the dispute possibly be about?

I also noticed that in the last month or so all the usual references
to the Axolotl protocol were renamed to the double ratchet protocol
or "Signal Protocol."  The timing may be a coincidence or maybe not.

So I searched for any trademarks and sure enough there is a live
trademark for the word Axolotl (registration number 2798167):

    Computer software for use in the field of health care,
    namely, for providing communication ...

I guess the WhatsApp lawyers were not happy about that.

I may be totally wrong.  But the lesson remains: always check for
trademarks before naming your projects, even for open-source, and
certainly before doing business.

USPTO TESS: <http://tess2.uspto.gov/>

Good luck to all.

(Continue reading)

Ron Garret | 5 May 20:45 2016

You can be too secure


On May 5, 2016, at 11:13 AM, Kevin <kevinsisco61784@...> wrote:

> One can never be to secure!

Actually, I learned the hard way last week that this is not true.

Four years ago I bought a 2010 MacBook air from a private party (i.e. I’ve owned it for four years, and it was
two years old when I bought it).  I did a clean install of OS X, and used the machine with no problems for the
next four years.

Last week, someone apparently put an iCloud lock on the machine.  It turns out that wiping the hard drive does
not remove the machine’s iCloud binding.  If the machine has been associated with an iCloud account at
any time in its history, only the owner of the associated account (or Apple) can remove that binding.  And
Apple will only do it if you can produce a proof-of-purchase, which for them is a receipt from an authorized
reseller.  The iCloud lock is implemented in EFI firmware, so not even replacing the internal drive will
remove it.

It gets worse: Apple refuses to contact the owner of the iCloud account that placed the lock.  The lock
message provides no information (it simply says, “Machine locked pending investigation.”)  So even
if the machine I bought was stolen (I have a lot of evidence that it wasn’t, but no proof) I can’t return
it to its rightful owner because I have no idea who it is.  Apple knows, but they won’t tell me (which is
understandable) nor will they contact that person on my behalf (which is not).  They also don’t provide
any way of checking whether a Mac has an existing iCloud binding.  (They provide this service for mobile
devices, but not for Macs.)  The only way to tell is to take the machine into an Apple store and have them check it.

IMHO that’s too secure.

rg
(Continue reading)

shawn wilson | 5 May 11:40 2016
Picon

Kernel space vs userspace RNG

Just reflecting on the Linux RNG thread a bit ago, is there any technical reason to have RNG in kernel space? There are things like haveged which seem to work really well and putting or charging code in any kernel can be a bit of a battle (as it should be with code as complex as that involving crypto - wouldn't want people missing an exploit your new system exposes and accepting it*). So I wonder what the gain is for putting RNGs in the kernel.

The only argument I can think of against this is non technical - if you rely on users to pick their RNG implementation, they are liable to get it wrong. This may be valid but I'm still curious about the technical reasons for RNG in kernel space.

Also, if kernel space is really necessary, I'd think publishing as a dkms type package would gain more traction for getting into mainline (but this is probably OT here)

* Obviously that same argument can be made of userspace programs but I'd much prefer my exploits happen at a less privileged ring whenever possible :)

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Fedor Brunner | 25 Apr 08:58 2016
Picon

ZRTP Metadata

Each instance of ZRTP has a unique 96-bit random ZRTP ID, or ZID that is
generated once at installation time. ZID is transfered in plaintext so
even a passive attacker can learn lot of metadata information (which
uniquely identified ZRTP user communicates with a different uniquely
identified ZRTP user).

Because the ZID is unique for very long time a passive attacker can
track a ZRTP user over long time, over many networks (The ZIP stays
unique even when IP address changes).

For example SDES/SRTP doesn't leak this metadata information.

It's possible to operate ZRTP in cacheless mode and generate a new ZID
for every connection,
https://tools.ietf.org/html/rfc6189#section-4.9.1
but this cacheless operation would sacrifice the key continuity features.
https://tools.ietf.org/html/rfc6189#section-15.1

I think that the key continuity features of ZRTP are very useful because
they provide post-quantum confidentiality if two ZRTP users
can create at least a single connection over trusted network.

What are you thinking about ZRTP leaking metadata? What are the possible
solutions? For example encrypting the ZRTP packets with SDES/SRTP.

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
John Young | 30 Mar 02:11 2016
Picon

USG-Apple Orders to Assist Search and Decrypt Vacated

USG-Apple Orders to Assist Search and Decrypt Vacated

https://cryptome.org/2016/03/usg-apple-210.pdf
John Young | 29 Mar 12:35 2016
Picon

Re: [Cryptography] USG Moves to Vacate Apple Decrypt Order

At 11:22 PM 3/28/2016, Phillip Hallam-Baker wrote:
>Some random thoughts
>
>* Apple wins big. First, they beat off the FBI warrant, second
>everyone with less than a 5s has to buy a new phone.
>
>* The new phone might still be crackable by someone who has the tools
>to reverse the secure enclave. But Apple isn't one of the parties that
>can do that.
>
>* FBI might in future be able to subpoena information to use it for
>making a break attempt against the secure enclave.
>
>* If your security depends on someone else refusing to obey a
>subpoena, change your security.
>
>* If their security depends on you refusing to obey a subpoena, get 
>another job.

USG wins by assault, PR, obscurity, secrecy, and sanctification of 
the justice-court system.

No substantiation yet of USG access to Farook's phone. The claim 
could be a ploy to raise doubt about Apple security, and have the 
same effect as if access was successful. This would
take the public and political pressure off USG without having to 
disclose how access was obtained. As well as improve USG reputation 
for prowess, determination and triumph.

Deception, lies, bluffs and ploys are obligatory in legal proceedings 
and all stripes of security. Doubt, braggardy, obscurity and secrecy 
are essential features of defensive and aggressive security whether 
governmental, commercial or personal.
John Young | 29 Mar 00:27 2016
Picon

USG Moves to Vacate Apple Decrypt Order

USG Moves to Vacate Apple Decrypt Order

<https://t.co/qkQflTOzru>https://cryptome.org/2016/03/usg-apple-209.pdf 
John Young | 22 Mar 23:32 2016
Picon

USG-Apple Oral Proceedings Transcript 21 March 2016

USG-Apple Oral Proceedings Transcript 21 March 2016

<https://t.co/PTKsosDkYt>https://cryptome.org/2016/03/usg-apple-transcript-16-0321.pdf 
John Young | 22 Mar 01:43 2016
Picon

USG-Apple Hearing Vacated, Decrypt Order Stayed

https://cryptome.org/2016/03/usg-apple-199.pdf

Quote:

The court and counsel conferred regarding the government's Ex Parte Application
for a Continuance (docket no. 191). Based on the good cause shown in 
that application,
and based on Apple's nonobjection to vacating the hearing, the court ORDERS:

1. The hearing in this matter set for March 22, 2016 at 1:00 p.m. is
VACATED;

2. As there is presently uncertainty surrounding the government's need for
Apples's assistance, the court's February 16, 2016 Order Compelling 
Apple, Inc. to
Assist Agents in Search, in case number ED 15-451-M, is hereby 
stayed, pending further
submissions in this case; and

3. The government is ordered to file a status report by April 5, 2016.

Unquote

Docket No. 191:

https://cryptome.org/2016/03/usg-apple-191.pdf

Gmane