Jeffrey Walton | 2 Jul 21:39 2016

Symantec to Acquire Blue Coat and Define the Future of Cybersecurity

It feels like there's a loss of separation of concerns between CA unit
and the Interception unit under the Symantec umbrella. Given
Symantec's track record, I'm kind of suspicious.

MOUNTAIN VIEW, Calif. and SUNNYVALE, Calif. – June 12, 2016 – Symantec
(NASDAQ: SYMC) and Blue Coat, Inc. today announced that they have
entered into a definitive agreement under which Symantec will acquire
Blue Coat for approximately $4.651 billion in cash. The transaction
has been approved by the Boards of Directors of both companies and is
expected to close in the third calendar quarter of 2016. Greg Clark,
Chief Executive Officer of Blue Coat, will be appointed Chief
Executive Officer of Symantec and join the Symantec Board upon closing
of the transaction.

Blue Coat is the #1 market share leader and share gainer in Web
Security with a widely recognized portfolio of integrated technologies
serving as a trusted platform to deliver Cloud Generation Security to
more than 15,000 customers worldwide. For Blue Coat’s fiscal year
ending April 30, 2016, GAAP revenue was $598 million and non-GAAP
revenue was $755 million, with 17% year-over-year growth, supported by
new products and new customers. For the same time period, the company
had non-GAAP operating margins of 22% and cash flow from operations of
$135 million. Also for this time period, GAAP operating margins were
cryptography mailing list
cryptography <at>
(Continue reading)

Ron Garret | 24 Jun 21:11 2016

Fwd: MalwareBytes

I originally sent this to John Levine privately, but the discussion seems to have leaked onto this list so
I’m re-sending my response to John here for the record.

Begin forwarded message:

> From: Ron Garret <ron@...>
> Subject: Re: [cryptography] MalwareBytes
> Date: June 24, 2016 at 11:50:08 AM PDT
> To: "John R. Levine" <johnl@...>
> [Responding privately, just in case I’m being an idiot, which is entirely possible]
> On Jun 24, 2016, at 11:35 AM, John R. Levine <johnl@...> wrote:
>>> But all of this is rather a moot point nowadays.  Now that letsencrypt is live, there is no reason to pay for
a cert any more.
>> Try getting a let's encrypt cert for your mail server.
> Why would that be a problem?  Don’t mail servers use the same X509 certs that web servers do?
>> Or getting an EV cert.
> Why would you need one?  Are there any browsers out there that actually distinguish between EV and DV certs?
> rg
rvh40 | 21 Jun 19:25 2016


I just downloaded the new MBAM installer.

Its certificate expired 6/19/2016.

Should I just ignore that fact?
Jeffrey Walton | 11 Jun 01:50 2016

RDRAND not really random with Oracle Studio 12.3 + patches

Ouch... just came across this...

I did not think it was possible to foul the hardware generated random
numbers (sans an occasional underflow).

travis+ml | 1 Jun 00:15 2016

papers on Chinese SMx algos

Does anyone have good English docs on the Chinese SMx algorithms?
Interested in descriptions and analyses, similarities to US standards etc.

-- | if spammer then john@...
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977
Ron Garret | 25 May 17:25 2016

Stealthy analog trojans

Coming soon to a microprocessor near you
grarpamp | 18 May 08:38 2016

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
Explicit Two-Source Extractors and Resilient Functions.

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

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.


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.

(Continue reading)

shawn wilson | 5 May 11:40 2016

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
Fedor Brunner | 25 Apr 08:58 2016

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,
but this cacheless operation would sacrifice the key continuity features.

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