Without doing any key management or requiring some kind of reliable
identity or memory of previous sessions, the best we can do in the inner
protocol is an ephemeral Diffie-Hellman, so suppose we do this:
a. Generate random a and send aG on curve P256
b. Generate random b and send bG on
On 2013-10-11 15:48, ianG wrote:
Right now we've got a TCP startup, and a TLS startup. It's pretty
messy. Adding another startup inside isn't likely to gain popularity.
The problem is that layering creates round trips, and as cpus get ever
faster, and pipes ever fatter, round trips become a
On 10 October 2013 17:06, John Kelsey crypto@gmail.com wrote:
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So
imagine that we have a widely-used inner-level
On Oct 11, 2013, at 11:09 PM, James A. Donald wrote:
Right now we've got a TCP startup, and a TLS startup. It's pretty messy.
Adding another startup inside isn't likely to gain popularity.
The problem is that layering creates round trips, and as cpus get ever
faster, and pipes ever
On Oct 12, 2013, at 6:51 AM, Ben Laurie b...@links.org wrote:
...
AIUI, you're trying to make it so that only active attacks work on the
combined protocol, whereas passive attacks might work on the outer
protocol. In order to achieve this, you assume that your proposed
inner protocol is not
On Oct 11, 2013, at 1:48 AM, ianG i...@iang.org wrote:
...
What's your goal? I would say you could do this if the goal was ultimate
security. But for most purposes this is overkill (and I'd include online
banking, etc, in that).
We were talking about how hard it is to solve crypto
On 10/10/13 19:06 PM, John Kelsey wrote:
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So imagine
that we have a widely-used inner-level protocol that can use strong
On 10/10/13 08:41 AM, Bill Frantz wrote:
We should try to characterize what a very long time is in years. :-)
Look at the produce life cycle for known crypto products. We have some
experience of this now. Skype, SSL v2/3 - TLS 0/1/2, SSH 1 - 2, PGP 2
- 5+.
As a starting point, I would
On 10/10/13 17:58 PM, Salz, Rich wrote:
TLS was designed to support multiple ciphersuites. Unfortunately this opened
the door
to downgrade attacks, and transitioning to protocol versions that wouldn't do
this was nontrivial.
The ciphersuites included all shared certain misfeatures, leading to
I like the ideas, John.
The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer the higher
or outer layer a way to hook into the crypto from your inner layer.
On 10/11/13 at 10:32 AM, zoo...@gmail.com (Zooko O'Whielacronx) wrote:
Don't try to study
foolscap, even though it is a very interesting practical approach,
because there doesn't exist documentation of the protocol at the right
level for you to learn from.
Look at the E language sturdy refs,
On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx zoo...@gmail.com wrote:
I like the ideas, John.
The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So imagine
that we have a widely-used inner-level protocol that can use strong crypto, but
also requires no external key
On 10/9/13 at 7:18 PM, crypto@gmail.com (John Kelsey) wrote:
We know how to address one part of this problem--choose only
algorithms whose design strength is large enough that there's
not some relatively close by time when the algorithms will need
to be swapped out. That's not all that
On 10/9/13 at 7:12 PM, watsonbl...@gmail.com (Watson Ladd) wrote:
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
... As professionals, we have an obligation to share our
knowledge of the limits of our technology with the people who
are depending on it. We know that
Watson Ladd watsonbl...@gmail.com writes:
The obvious solution: Do it right the first time.
And how do you know that you're doing it right? PGP in 1992 adopted a
bleeding-edge cipher (IDEA) and was incredibly lucky that it's stayed secure
since then. What new cipher introduced up until 1992
TLS was designed to support multiple ciphersuites. Unfortunately this opened
the door
to downgrade attacks, and transitioning to protocol versions that wouldn't do
this was nontrivial.
The ciphersuites included all shared certain misfeatures, leading to the
current situation.
On the
On 10 Oct 2013, at 17:06, John Kelsey crypto@gmail.com wrote:
Just thinking out loud
The administrative complexity of a cryptosystem is overwhelmingly in key
management and identity management and all the rest of that stuff. So
imagine that we have a widely-used inner-level
More random thoughts:
The minimal inner protocol would be something like this:
Using AES-CCM with a tag size of 32 bits, IVs constructed based on an implicit
counter, and an AES-CMAC-based KDF, we do the following:
Sender:
a. Generate random 128 bit value R
b. Use the KDF to compute
On 2013-10-10 (283), at 15:29:33, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
On 10 Oct 2013, at 17:06, John Kelsey crypto@gmail.com wrote:
Just thinking out loud
[]
c. Both sides derive the shared key abG, and then use SHAKE512(abG) to
generate an AES key for
On Oct 10, 2013, at 5:15 PM, Richard Outerbridge ou...@sympatico.ca wrote:
How does this prevent MITM? Where does G come from?
I'm assuming G is a systemwide shared parameter. It doesn't prevent
mitm--remember the idea here is to make a fairly lightweight protocol to run
*inside* another
On Thu, Oct 10, 2013 at 3:32 PM, John Kelsey crypto@gmail.com wrote:
The goal is to have an inner protocol which can run inside TLS or some
similar thing
[...]
Suppose we have this inner protocol running inside a TLS version that is
subject to one of the CBC padding reaction attacks.
On Thursday, October 10, 2013, Salz, Rich wrote:
TLS was designed to support multiple ciphersuites. Unfortunately this
opened the door
to downgrade attacks, and transitioning to protocol versions that
wouldn't do this was nontrivial.
The ciphersuites included all shared certain
On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter leich...@lrw.com wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
If we can't select ciphersuites that we are sure we will always be
comfortable with (for at least some forseeable lifetime) then we urgently
need the
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
We seriously need to consider what the design lifespan of our
crypto suites is in real life. That data should be
communicated to hardware and software
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
We seriously need to consider what the design lifespan of our crypto suites
is in
On Oct 8, 2013, at 4:46 PM, Bill Frantz fra...@pwpconsult.com wrote:
I think the situation is much more serious than this comment makes it appear.
As professionals, we have an obligation to share our knowledge of the limits
of our technology with the people who are depending on it. We know
On 10/6/13 at 8:26 AM, crypto@gmail.com (John Kelsey) wrote:
If we can't select ciphersuites that we are sure we will always
be comfortable with (for at least some forseeable lifetime)
then we urgently need the ability to *stop* using them at some
point. The examples of MD5 and RC4 make
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com wrote:
If we can't select ciphersuites that we are sure we will always be
comfortable with (for at least some forseeable lifetime) then we urgently
need the ability to *stop* using them at some point. The examples of MD5
and RC4
On Sat, Oct 05, 2013 at 09:29:05PM -0400, John Kelsey wrote:
One thing that seems clear to me: When you talk about algorithm
flexibility in a protocol or product, most people think you are
talking about the ability to add algorithms. Really, you are talking
more about the ability to *remove*
On Sat, Oct 5, 2013 at 7:36 PM, James A. Donald jam...@echeque.com wrote:
On 2013-10-04 23:57, Phillip Hallam-Baker wrote:
Oh and it seems that someone has murdered the head of the IRG cyber
effort. I condemn it without qualification.
I endorse it without qualification. The IRG are bad
On 2013-10-07 01:18, Phillip Hallam-Baker wrote:
We are not at war with Iran.
We are not exactly at peace with Iran either, but that is irrelevant,
for presumably it was a Jew that did it, and Iran is at war with Jews.
(And they are none too keen on Christians, Bahais, or Zoroastrians
On Oct 5, 2013, at 9:29 PM, John Kelsey wrote:
One thing that seems clear to me: When you talk about algorithm flexibility
in a protocol or product, most people think you are talking about the ability
to add algorithms. Really, you are talking more about the ability to
*remove*
Is it just me, or does the government really have absolutely no one
with any sense of irony? Nor, increasingly, anyone with a sense of
shame?
I have to ask, because after directly suborning the cyber security
of most of the world including the USA, and destroying the credibility
of just about
-Willem van Gulik di...@webweaving.org
Subject: Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
NIST about to weaken SHA3?
On Oct 5, 2013, at 9:29 PM, John Kelsey wrote:
Really, you are talking more about the ability to *remove* algorithms. We
still have stuff using
On Oct 7, 2013, at 12:45 PM, Ray Dillinger b...@sonic.net wrote:
Can we do anything ...[to make it possible to remove old algorithms]? If the
protocol allows correction (particularly remote or automated correction) of
an entity using a weak crypto primitive, that opens up a whole new set of
On Sun, Oct 6, 2013 at 11:26 AM, John Kelsey crypto@gmail.com wrote:
If we can't select ciphersuites that we are sure we will always be
comfortable with (for at least some forseeable lifetime) then we urgently
need the ability to *stop* using them at some point. The examples of MD5
and
On 2013-10-04 23:57, Phillip Hallam-Baker wrote:
Oh and it seems that someone has murdered the head of the IRG cyber
effort. I condemn it without qualification.
I endorse it without qualification. The IRG are bad guys and need
killing - all of them, every single one.
War is an honorable
One thing that seems clear to me: When you talk about algorithm flexibility in
a protocol or product, most people think you are talking about the ability to
add algorithms. Really, you are talking more about the ability to *remove*
algorithms. We still have stuff using MD5 and RC4 (and we'll
On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker hal...@gmail.com wrote:
...
Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had no
impact on the security of certificates issued using MD5 until the attack was
dramatically improved and the second pre-image attack became
On Fri, Oct 4, 2013 at 10:23 AM, John Kelsey crypto@gmail.com wrote:
On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker hal...@gmail.com
wrote:
...
Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had
no impact on the security of certificates issued using MD5 until the
On Oct 2, 2013, at 7:46 AM, John Kelsey crypto@gmail.com wrote:
Has anyone tried to systematically look at what has led to previous crypto
failures? T
In the case we are now, I don't think that it is actually crypto failures
(RSA is still secure, but 1024 bit is not. 2048 DHE is still
On 02/10/13 18:42, Arnold Reinhold wrote:
On 1 Oct 2013 23:48 Jerry Leichter wrote:
The larger the construction project, the tighter the limits on this stuff. I used to work with a former structural
engineer, and he repeated some of the bad example stories they are taught. A famous case a
On 2013-10-03 00:46, John Kelsey wrote:
a. Most attacks come from protocol or mode failures, not so much crypto
primitive failures. That is, there's a reaction attack on the way CBC
encryption and message padding play with your application, and it doesn't
matter whether you're using AES or
On 2/10/13 17:46 PM, John Kelsey wrote:
Has anyone tried to systematically look at what has led to previous crypto
failures?
This has been a favourite topic of mine, ever since I discovered that
the entire foundation of SSL was built on theory, never confirmed in
practice. But my views are
On Oct 1, 2013, at 12:27 PM, Dirk-Willem van Gulik wrote:
It's clear what 10x stronger than needed means for a support beam: We're
pretty good at modeling the forces on a beam and we know how strong beams of
given sizes are.
Actually - do we ? I picked this example as it is one of those
Has anyone tried to systematically look at what has led to previous crypto
failures? That would inform us about where we need to be adding armor plate.
My impression (this may be the availability heuristic at work) is that:
a. Most attacks come from protocol or mode failures, not so much
maybe offtopic
On Tue, 1 Oct 2013, someone who (if I've unwrapped the nested quoting
correctly) might have been Jerry Leichter wrote:
There are three levels of construction. If you're putting together
a small garden shed, it looks right is generally enough - at least
if it's someone with
On 1 Oct 2013 23:48 Jerry Leichter wrote:
The larger the construction project, the tighter the limits on this stuff. I
used to work with a former structural engineer, and he repeated some of the
bad example stories they are taught. A famous case a number of years back
involved a hotel
Op 30 sep. 2013, om 05:12 heeft Christoph Anton Mitterer
cales...@scientia.net het volgende geschreven:
Not sure whether this has been pointed out / discussed here already (but
I guess Perry will reject my mail in case it has):
https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3
On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik di...@webweaving.org wrote:
...I do note that in crypto (possibly driven by the perceived expense of too
many bits) we tend to very carefully observe the various bit lengths found in
800-78-3, 800-131A , etc etc. And rarely go much beyond it*.
Op 1 okt. 2013, om 17:59 heeft Jerry Leichter leich...@lrw.com het volgende
geschreven:
On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik di...@webweaving.org
wrote:
...I do note that in crypto (possibly driven by the perceived expense of too
many bits) we tend to very carefully observe
On 10/1/13 at 12:29 AM, di...@webweaving.org (Dirk-Willem van
Gulik) wrote:
While in a lot of other fields - it is very common for 'run of
the mill' constructions; such as when calculating a floor,
wooden support beam, a joist, to take the various standards and
liberally apply safety
53 matches
Mail list logo
