> 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
On Oct 12, 2013, at 6:51 AM, Ben Laurie 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 vulnerable to
On 10 October 2013 17:06, 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 s
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 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 Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx 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 the "higher
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, w
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/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 wo
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 t
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 crypto
On Oct 11, 2013, at 1:48 AM, ianG 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 protocol problems
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 mis
On Thu, Oct 10, 2013 at 3:32 PM, John Kelsey 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. The inner protoc
On Oct 10, 2013, at 5:15 PM, Richard Outerbridge 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 crypto protocol li
On 2013-10-10 (283), at 15:29:33, Stephen Farrell
wrote:
>> On 10 Oct 2013, at 17:06, John Kelsey wrote:
>>
>> Just thinking out loud
>>
[]
>> c. Both sides derive the shared key abG, and then use SHAKE512(abG) to
>> generate an AES key for messages in each direction.
How does th
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 K[S],N[S
> On 10 Oct 2013, at 17:06, 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 c
> 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
Watson Ladd 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 has had that
distinctio
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 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 all crypto standards wh
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 bi
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 manage
On Oct 8, 2013, at 4:46 PM, Bill Frantz 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 that all
> crypto s
On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz 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 wrote:
>
>
>>> We seriously need to consider what the design lifespan of our crypto suites
>>> is in real life. That data should be
On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 designers so they know
what
On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter wrote:
> On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 so
On Oct 8, 2013, at 1:11 AM, Bill Frantz 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 that pre
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 t
On Sun, Oct 6, 2013 at 11:26 AM, 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 that pret
On Oct 7, 2013, at 12:45 PM, Ray Dillinger 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
> attacks on
Original message
From: Jerry Leichter
Date: 10/06/2013 15:35 (GMT-08:00)
To: John Kelsey
Cc: "cryptography@metzdowd.com List" ,Christoph
Anton Mitterer ,james hughes
,Dirk-Willem van Gulik
Subject: Re: [Cryptography] Crypto Standards v.s. Engineering ha
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 eve
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* algorit
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 either)
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 that
pretty clear.
Ceasing to use one particular encryption algor
On Sat, Oct 5, 2013 at 7:36 PM, James A. Donald 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 guys and ne
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 *remo
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 pro
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 2, 2013, at 7:46 AM, John Kelsey 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 secure, but no on
On Fri, Oct 4, 2013 at 10:23 AM, John Kelsey wrote:
> On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker
> 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 impro
On Thu, Oct 3, 2013 at 5:17 AM, ianG wrote:
> 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 Thu, Oct 3, 2013 at 5:38 AM, Alan Braggins wrote:
> 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
>
On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker 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 feasible.
Just a
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 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 F
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 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 hot
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 sufficient expe
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 cryp
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
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 factors.
Op 1 okt. 2013, om 17:59 heeft Jerry Leichter het volgende
geschreven:
> On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik
> 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
>
On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik 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*.
>
> While in a l
Op 30 sep. 2013, om 05:12 heeft Christoph Anton Mitterer
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
> This makes NIS
56 matches
Mail list logo