Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

"I prefer to think that God is not dead, just drunk" -- John Huston


rocksolid / Security / Linux can do Speck now

SubjectAuthor
* Linux can do Speck nowGuest
`* Re: Linux can do Speck nowAnonUser
 `- Re: Linux can do Speck nowanon

1
Subject: Linux can do Speck now
From: Guest
Newsgroups: rocksolid.shared.security
Organization: RetroBBS II
Date: Mon, 4 Jun 2018 16:43 UTC
Path: rocksolid2!.POSTED.localhost!not-for-mail
From: gue...@retrobbs.rocksolidbbs.com (Guest)
Newsgroups: rocksolid.shared.security
Subject: Linux can do Speck now
Date: Mon, 04 Jun 2018 16:43:22 +0000
Organization: RetroBBS II
Lines: 982
Message-ID: <pf3q7a$v2p$1@novabbs.com>
Reply-To: Guest <guest@retrobbs.rocksolidbbs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 4 Jun 2018 16:43:22 -0000 (UTC)
Injection-Info: novabbs.com; posting-host="localhost:127.0.0.1";
logging-data="31833"; mail-complaints-to="usenet@novabbs.com"
User-Agent: FUDforum 3.0.7
X-FUDforum: d41d8cd98f00b204e9800998ecf8427e <299123>
View all headers
Don't use it, it was written by the NSA:

https://www.spinics.net/lists/linux-crypto/msg33291.html

[PATCH v2 0/5] crypto: Speck support
[Date Prev][Date Next][Thread Prev][Thread Next][Date
Index][Thread Index]

     Subject: [PATCH v2 0/5] crypto: Speck support
    From: Tomer Ashur <tomer.ashur@xxxxxxxxxxxxxxxx>
    Date: Fri, 1 Jun 2018 21:23:28 +0200
    Cc: Samuel Neves <samuel.c.p.neves@xxxxxxxxx>, "Jason A.
Donenfeld" <Jason@xxxxxxxxx>, Linux Crypto Mailing List
<linux-crypto@xxxxxxxxxxxxxxx>, Herbert Xu
<herbert@xxxxxxxxxxxxxxxxxxx>,
linux-fscrypt@xxxxxxxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx>, Jeffrey Walton
<noloader@xxxxxxxxx>, Paul Crowley <paulcrowley@xxxxxxxxxx>,
Patrik Torstensson <totte@xxxxxxxxxx>, Greg Kaiser
<gkaiser@xxxxxxxxxx>, Paul Lawrence
<paullawrence@xxxxxxxxxx>, Michael Halcrow
<mhalcrow@xxxxxxxxxx>, Alex Cope <alexcope@xxxxxxxxxx>, Greg
Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
    In-reply-to:
<mailto:8c9dc804-1f59-a245-57ba-51db3c234621@esat.kuleuven.be>
    Openpgp: preference=signencrypt
    References:
<mailto:8c9dc804-1f59-a245-57ba-51db3c234621@esat.kuleuven.be>
    User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0)
Gecko/20100101 Thunderbird/52.8.0

[Resending because the email bounced back from all 3 mailing
lists.
Sorry if you get this email twice]
Hi Eric et al.,
I know that this thread is already stale, and I'm sorry I
couldn't join
earlier but maybe late is better than never. Allow me to
first introduce
myself: my name is Tomer Ashur and I'm a post-doctoral
fellow in KU
Leuven. I am part of symmetric-key group led by Vincent
Rijmen where I'm
mostly involved in cryptanalysis. I am also part of ISO/IEC
JTC 1/SC
27/WG 2, the group which decided to reject Simon and Speck
from ISO. If
it's okay with you, I'd like to give my perspective on what
happened in
ISO and what is Speck's real standing with the academic
community.

First, I'd like to say that the NSA has done quite extensive
work in
muddying the waters, arguing that Simon & Speck are secure
and that all
objections are political. This is not true, as I will now
show with
examples. The bottom line is that there are still many open
questions
about their security, questions that the NSA has, on
multiple occasions,
refused to answer.

It seems to me justified about as well as one would hope
for a new cipher -   "Notes on the design and analysis of Simon and Speck"
seems to me to give ... detail on the reasoning
This is actually an optical illusion. First you need to
understand the
context for this document. The NSA (in particular, the exact
same person
who previously promoted DUAL_EC in ISO) proposed to include
Simon &
Speck in ISO/IEC 29192-2 back in 2015. For obvious reasons
they were met
with skepticism. A main concern was the lack of any design
rationale and
internal cryptanalytic results. The NSA people fought tooth
and nail for
a year and a half simultaneously arguing two almost
mutually-exclusive
points: (i) they employ the most talented cryptographers and
hence, we
should trust them when they say that an algorithm is secure;
and (ii)
they are average cryptographers and hence they would not be
able to
insert a backdoor into the algorithm.

More than once they argued in a meeting that the
cryptanalysis for the
ciphers has been stabilized (i.e., that attacks will not
improve) just
to be proved wrong in the next meeting (their answer: "well,
_now_ it
has fully stabilized", which was again proven wrong in the
next
meeting). One of them even had a bet with Tanja Lange that
no attack on
either Simon or Speck would be extended by 3 rounds or more
in the
upcoming year. He lost this bet. They were very
uncooperative, and made
it a point to let us know that they will not be providing
more
information about the algorithms.

So, in this climate, you can imagine how surprised we all
were when in
one of the meetings (after not getting the votes they needed
in order to
proceed to the next stage) they announced that they will
provide a
design rationale. At first they distributed it to us in ISO,
but per my
suggestion they then uploaded it to ePrint (see ePrint
2017/560).

But our joy was short-lived. Once you read this so-called
design
rationale you can immediately notice two things. Firstly,
that they
explain in length all decisions affecting performance (in
particular,
rotation amounts - which in one of the meetings they
described as
"most-efficient; secure-enough"). The second thing is that
when it comes
to cryptanalysis this document is merely a literature
review. There is
literally nothing new there - all they do is to cite
published works by
academics, something wrongly.

Now, there is no nice way to say that, but this document
includes
omissions, falsehoods, half-truths and outright lies. I will
not go into
the full analysis of the document, but here are some
examples:

 1. Omissions - I already said that this document does not
provide any
    new information. This becomes apparent when you try to
find out how
    they chose the number of rounds. The document remains
quite vague on
    this question. There is a lot of hand waving about
"Matsui-like
    techniques", "multipath effect", etc. but nowhere you
can find (in
    the old version, they recently uploaded a new version
which I didn't
    have time to read yet) a place where they say: "this is
how we set
    the number of rounds".

    Another omission is about the key schedule - you won't
find any
    useful information about the design decisions leading to
these
    particular key schedules. Simon uses 3 matrices U,V, and
W which are
    not explained, not does the constant c. Speck's key
schedule is more
    straightforward but a discussion about the symmetries
that may arise
    from using the round function for the key schedule would
still be
    appropriate here. Not discussing the combined security
of the cipher
    with its key schedule goes against the current trend in
linear
    cryptanalysis (see e.g., [2] and many follow up
papers).
 2. Half-truths -  take a look at page 16 where they explain
how they
    avoided rotation/slide attacks. They give the standard
explanation
    that using round-constants would thwart these attacks.
This could
    have been fine if the last sentence wasn't "/Also see
[AL16]/". From
    the text it seems as if /AL16/ supports the claims made
in this
    paragraph. However, /AL16/ is a paper I co-authored
which is how I
    know that not only that it doesn't support the claim, it
actually
    shows how to adapt rotational cryptanalysis to
algorithms using
    round constants.

    As a side note, the goal of /AL16/ was to present a
novel way to use
    rotational cryptanalysis in the presence of round
constants. This
    paper was published in FSE'17 and we followed up on it
with a paper
    in FSE'18 using this attack against Speck{32,48,64} [1].
The reason
    we focused on these versions and not the larger one is
not, as was
    suggested in this thread, that they are somehow more
secure. The
    actual reason is much less prosaic: these are the
resources we had
    at our disposal. This is also the reason the weak-key
classes are so
    small. But the fact that my publicly funded university
cannot afford
    a better number cruncher doesn't mean that someone with
access to
    such won't be able to find better results. In fact, I am
quite
    convinced that if you give our tool the resources it
needs, it would
    penetrate way more than the currently best known
distinguisher of 19
    rounds for Speck128 (translating to better key recovery
attacks).

    What is important to understand here is in the same way
you do
    "real-world crypto", academics often do "proofs of
concept". After
    publishing the attack technique and the attack on
(reduced-)Speck, I
    moved to my next project because the scientific marginal
benefit is
    small. There is of course the personal gain of being
known as the
    guy who broke Speck, but I'm not particularly interested
in such
    fame. All of that being said, if anyone has the
firepower to run
    this tool and to improve the existing attacks for
Speck128, feel
    free to drop me an email.
 3. Falsehoods - with this word I refer to claims in the
so-called
    design rationale that are wrong. We can argue whether
they were
    included on purpose or if they are simply mistakes. But

Click here to read the complete article
Subject: Re: Linux can do Speck now
From: AnonUser
Newsgroups: rocksolid.shared.security
Organization: RetroBBS
Date: Tue, 5 Jun 2018 09:46 UTC
References: 1
Path: rocksolid2!.POSTED.retrobbs!not-for-mail
From: anonu...@retrobbs.rocksolidbbs.com.remove-ov0-this (AnonUser)
Newsgroups: rocksolid.shared.security
Subject: Re: Linux can do Speck now
Date: Tue, 5 Jun 2018 02:46:39 -0700
Organization: RetroBBS
Message-ID: <0300a0c58d37af2a7404eacd4a95ef33$1@retrobbs.i2p>
References: <pf3q7a$v2p$1@novabbs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: novabbs.com; posting-host="retrobbs:10.128.3.129";
logging-data="24246"; mail-complaints-to="usenet@novabbs.com"
To: Guest
X-Comment-To: Guest
In-Reply-To: <pf3q7a$v2p$1@novabbs.com>
X-FTN-PID: Synchronet 3.17a-Linux Feb 20 2018 GCC 6.3.0
X-Gateway: retrobbs.rocksolidbbs.com [Synchronet 3.17a-Linux NewsLink 1.108]
View all headers
  To: Guest
Haven't finished reading this yet, but

"it is clear that this document is meant for PR and has no scientific value."

"Were you aware of all these
results when you
published the algorithms, or are any of them better than
what you knew of?
   - A: I refuse to answer that
   -Q: Are you aware of any cryptanalytic results better
than those
already found by academia?
   -A: I refuse to answer that either."

NSA is a political organization with political goals. Their interest in protecting people's data is not there. Their only interest is in accessing people's data. That's their job.

Whether the NSA is "evil" or not doesn't mean much when deciding whether to use their code, simply realizing it's their JOB to get your data should be enough to help make the decision.

Posted on RetroBBS
--- Synchronet 3.17a-Linux NewsLink 1.108
Posted on RetroBBS


Subject: Re: Linux can do Speck now
From: anon
Newsgroups: rocksolid.shared.security
Organization: def4
Date: Tue, 12 Jun 2018 22:08 UTC
References: 1
Path: rocksolid2!def3!.POSTED.localhost!not-for-mail
From: ano...@anon.com (anon)
Newsgroups: rocksolid.shared.security
Message-ID: <71aad247a673790c7c736510c@def4.com>
Subject: Re: Linux can do Speck now
Date: Tue, 12 Jun 2018 22:08:26+0000
Organization: def4
In-Reply-To: <0300a0c58d37af2a7404eacd4a95ef33$1@retrobbs.i2p>
References: <0300a0c58d37af2a7404eacd4a95ef33$1@retrobbs.i2p>
Lines:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
View all headers
or: "let me watch your kids for you, said the wolve to the sheep"

"grandma, why are you eyes so big" ?

lol

Posted on def4.i2p


1
rocksolid light 0.7.2
clearneti2ptor