Rocksolid Light

Welcome to Rocksolid Light

mail  files  register  newsreader  groups  login

Message-ID:  

Why use Windows, since there is a door? (By fachat@galileo.rhein-neckar.de, Andre Fachat)


computers / Security / Re: Linux can do Speck now

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

1
Linux can do Speck now

<pf3q7a$v2p$1@novabbs.com>

 copy mid

https://news.novabbs.org/computers/article-flat.php?id=325&group=rocksolid.shared.security#325

 copy link   Newsgroups: rocksolid.shared.security
Path: rocksolid2!.POSTED.localhost!not-for-mail
From: guest@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>
 by: Guest - Mon, 4 Jun 2018 16:43 UTC

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
in either
case, they are exist and they are worrisome. I would
only give one
example: "/the design team's early analytic efforts led
us to
believe that the limiting cryptanalytic features for
Simon and
Speck-type block ciphers would be of the linear and
differential
sort"/ (see Page 4). Believing that differential and
linear attacks
would be the most dangerous attacks is reasonable, but
as we can see
from [1], it is wrong.
4. Lies - this is the most troubling part. The NSA lies to
the public
(including the American people) on official documents. I
already
wrote that the choice for the exact number of rounds is
only
motivated through some hand waving. This makes it hard
to tell what
the real security margin is. But even if you interpret
the hand
waving conservatively, the math results in much smaller
security
margins than what is claimed. I gave a rump session talk
about this
in Crypto 2017 which you can view here [3]. The talk
focuses on
Simon but the story for Speck is similar and results in
security
margins of 15.6%, 15.6%, and 14.7% for Speck128 with key
sizes 128,
192, and 256, respectively. According to the NSA, that
is, and only
if you accept the claim that attacks have stabilized.


Click here to read the complete article
Re: Linux can do Speck now

<0300a0c58d37af2a7404eacd4a95ef33$1@retrobbs.i2p>

 copy mid

https://news.novabbs.org/computers/article-flat.php?id=326&group=rocksolid.shared.security#326

 copy link   Newsgroups: rocksolid.shared.security
Path: rocksolid2!.POSTED.retrobbs!not-for-mail
From: anonuser@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]
 by: AnonUser - Tue, 5 Jun 2018 09:46 UTC

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

Re: Linux can do Speck now

<71aad247a673790c7c736510c@def4.com>

 copy mid

https://news.novabbs.org/computers/article-flat.php?id=329&group=rocksolid.shared.security#329

 copy link   Newsgroups: rocksolid.shared.security
Path: rocksolid2!def3!.POSTED.localhost!not-for-mail
From: anon@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
 by: anon - Tue, 12 Jun 2018 22:08 UTC

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
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor