On Mon, Feb 11, 2008 at 07:01:07PM +1300, Peter Gutmann wrote:
> Daniel Carosone <[EMAIL PROTECTED]> writes:
> >[...]
> >Particularly for the first point, early validation for packet integrity in
> >general can be a useful defensive tool against unknown potential
> >implementation vulnerabilities.
Daniel Carosone <[EMAIL PROTECTED]> writes:
>On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
>> Additionally, in order to conserve bandwidth you might want to make a
>> trade-off where some packets may be forged with small probability (in the
>> VOIP case, that means an attack
| >All of this ignores a significant issue: Are keying and encryption
| >(and authentication) mechanisms really independent of each other? I'm
| >not aware of much work in this direction.
|
| Is there much work to be done here? If you view the keyex mechanism
| as a producer of an authenticated
"Leichter, Jerry" <[EMAIL PROTECTED]> writes:
>All of this ignores a significant issue: Are keying and encryption (and
>authentication) mechanisms really independent of each other? I'm not aware of
>much work in this direction.
Is there much work to be done here? If you view the keyex mechanism
At Thu, 7 Feb 2008 14:42:36 -0500 (EST),
Leichter, Jerry wrote:
> | > Obviously, if you *really* use every k'th packet to define what is in
> | > fact a substream, an attacker can arrange to knock out the substream he
> | > has chosen to attack. So you use your encryptor to permute the
> | > subst
>> humans are not going to carry around large strong secrets every time
either end of the connection restarts
Which is what makes good crypto challenging. I think, though, that
because people can understand the concept of physical locks and keys,
that this should be carried forward...
Good secur
| So, this issue has been addressed in the broadcast signature context
| where you do a two-stage hash-and-sign reduction (cf. [PG01]), but
| when this only really works because hashes are a lot more efficient
| than signatures. I don't see why it helps with MACs.
Thanks for the reference.
| > Obv
At Thu, 7 Feb 2008 10:34:42 -0500 (EST),
Leichter, Jerry wrote:
> | Since (by definition) you don't have a copy of the packet you've lost,
> | you need a MAC that survives that--and is still compact. This makes
> | life rather more complicated. I'm not up on the most recent lossy
> | MACing literat
| >I don't propose to get into an extended debate about whether it is
| >better to use SRTP or to use generic DTLS. That debate has already
| >happened in IETF and SRTP is what the VoIP vendors are
| >doing. However, the good news here is that you can use DTLS to key
| >SRTP (draft-ietf-avt-dtls-sr
> Thus unlike with bridges, you fundamentally can't
> evaluate the quality of a security system you built if you're unfamiliar
> with the state of the art of _attacks_ against security systems, and you
> can't become familiar with those unless you realize that these attacks
> have each brough
| > - Truncate the MAC to, say, 4 bytes. Yes, a simple brute
| > force attack lets one forge so short a MAC - but
| > is such an attack practically mountable in real
| > time by attackers who concern you?
|
| In fact, 32-bit authentication tags are a featur
Others have made similar points and suggestions, not picking on this
instance in particular:
On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
> Additionally, in order to conserve bandwidth you might want to make a
> trade-off where some packets may be forged with small probab
> Amateurs talk about algorithms. Professionals talk about economics.
That would be
Amateurs study cryptography; professionals study economics.
-- Allan Schiffman, 2 July 04
Quotationally yours,
--dan
-
The Cryptogra
[EMAIL PROTECTED] (Peter Gutmann) on Monday, February 4, 2008 wrote:
>Eric Rescorla <[EMAIL PROTECTED]> writes:
>
>>I don't propose to get into an extended debate about whether it is better to
>>use SRTP or to use generic DTLS. That debate has already happened in IETF and
>>SRTP is what the VoIP v
At Mon, 04 Feb 2008 14:29:50 +1000,
James A. Donald wrote:
>
> James A. Donald wrote:
> >> I have figured out a solution, which I may post here
> >> if you are interested.
>
> Ian G wrote:
> > I'm interested. FTR, zooko and I worked on part of
> > the problem, documented briefly here:
> > h
On Mon, 4 Feb 2008 09:33:37 -0500 (EST)
"Leichter, Jerry" <[EMAIL PROTECTED]> wrote:
> The NSA quote someone - Steve Bellovin? - has repeated comes to mind:
> Amateurs talk about algorithms. Professionals talk about economics.
> Using DTLS for VOIP provides you with an extremely high level of
> s
Comments inline.
On Feb 3, 2008, at 5:56 PM, Eric Rescorla wrote:
- If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
mode), plus 2 bytes of padding to bring you up to the AES block
boundary: DTLS adds 32 bytes of o
At Mon, 4 Feb 2008 09:33:37 -0500 (EST),
Leichter, Jerry wrote:
>
> Commenting on just one portion:
> | 2. VoIP over DTLS
> | As Perry indicated in another message, you can certainly run VoIP
> | over DTLS, which removes the buffering and retransmit issues
> | James is alluding to. Similarly, you
Commenting on just one portion:
| 2. VoIP over DTLS
| As Perry indicated in another message, you can certainly run VoIP
| over DTLS, which removes the buffering and retransmit issues
| James is alluding to. Similarly, you could run VoIP over IPsec
| (AH/ESP). However, for performance reasons, this
On Jan 31, 2008, at 10:32 PM, Richard Salz wrote:
Developers working in almost any field should know the history and
best
practices -- is PGP's original "bass o matic" any more important
than the
code in a defibrillator? -- but this is not the way our field works
right
now. Compare it to s
Eric Rescorla <[EMAIL PROTECTED]> writes:
>I don't propose to get into an extended debate about whether it is better to
>use SRTP or to use generic DTLS. That debate has already happened in IETF and
>SRTP is what the VoIP vendors are doing. However, the good news here is that
>you can use DTLS to
Ian G <[EMAIL PROTECTED]> writes:
>James A. Donald wrote:
>> I have been considering the problem of encrypted channels over UDP or
>> IP. TLS will not work for this, since it assumes and provides a
>> reliable, and therefore non timely channel, whereas what one wishes to
>> provide is a channel wh
Guus Sliepen <[EMAIL PROTECTED]> writes:
>Peter sent us his write-up up via private email a few days before he posted
>it to this list (which got it on Slashdot). I had little time to think about
>the issues he mentioned before his write-up became public.
I should provide some background for the
James A. Donald wrote:
>> I have figured out a solution, which I may post here
>> if you are interested.
Ian G wrote:
> I'm interested. FTR, zooko and I worked on part of
> the problem, documented briefly here:
> http://www.webfunds.org/guide/sdp/index.html
I have posted "How to do VPNs right"
At Sun, 03 Feb 2008 12:51:25 +1000,
James A. Donald wrote:
>
> --
> Ivan Krstic' wrote:
> > The wider point of Peter's writeup -- and of the
> > therapy -- is that developers working on security
> > tools should _know_ they're working in a notoriously,
> > infamously hard field where the
"James A. Donald" <[EMAIL PROTECTED]> writes:
> That point is of course true. But the developers wanted
> to transport IP and UDP. Peter should have known that
> SSL is incapable of transporting IP and UDP, because it
> will introduce large, unpredictable, and variable
> delays.
>
> If, for exam
--
Ivan Krstic' wrote:
> The wider point of Peter's writeup -- and of the
> therapy -- is that developers working on security
> tools should _know_ they're working in a notoriously,
> infamously hard field where the odds are
> _overwhelmingly_ against them if they choose to
> engineer new solu
On Fri, Feb 01, 2008 at 02:51:36PM +0800, Sandy Harris wrote:
> What I don't understand is why you think tinc is necessary,
> or even worth the trouble.
>
> IPsec is readily available -- built into Windows, Mac OS
> and various routers, and with implementations for Linux
> and all the *BSDs -- ha
Ian G <[EMAIL PROTECTED]> writes:
> This is what Guus was getting at:
>
>
> - We needed to tunnel data over UDP, with UDP semantics.
> SSL requires a reliable stream. Therefore, we had to
> use something other that SSL to tunnel data.
The version of SSL (which is officially called TLS) that d
On Fri, Feb 01, 2008 at 09:24:10AM -0500, Perry E. Metzger wrote:
> > Does tinc do something that IPsec cannot?
>
> I use a VPN system other than IPSec on a regular basis. The reason is
> simple: it is easy to configure for my application and my OS native
> IPsec tools are very difficult to config
James A. Donald wrote:
I have been considering the problem of encrypted channels over UDP or
IP. TLS will not work for this, since it assumes and provides a
reliable, and therefore non timely channel, whereas what one wishes to
provide is a channel where timeliness may be required at the expe
At Fri, 01 Feb 2008 18:42:03 +1000,
James A. Donald wrote:
>
> Guus Sliepen wrote:
> > Peter's write-up was the reason I subscribed to this cryptography
> > mailing list. After a while the anger/hurt feelings I had disappeared.
> > I knew then that Peter was right in his arguments. Nowadays I can
"James A. Donald" <[EMAIL PROTECTED]> writes:
>> When tinc 2.0 will ever come out (unfortunately I don't have a lot of
>> time to work on it these days), it will probably use the GnuTLS library
>> and authenticate and connect daemons with TLS. For performance reasons,
>> you want to tunnel network
"Sandy Harris" <[EMAIL PROTECTED]> writes:
> What I don't understand is why you think tinc is necessary,
> or even worth the trouble.
>
> IPsec is readily available -- built into Windows, Mac OS
> and various routers, and with implementations for Linux
> and all the *BSDs -- has had quite a bit of
Guus Sliepen wrote:
Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
at Peter's write-up more objectively and I can see that it is not as
What I don't understand is why you think tinc is necessary,
or even worth the trouble.
IPsec is readily available -- built into Windows, Mac OS
and various routers, and with implementations for Linux
and all the *BSDs -- has had quite a bit of expert
security analysis, and handles VPNs just fine.
> The wider point of Peter's writeup -- and of the therapy -- is that
> developers working on security tools should _know_ they're working in
> a notoriously, infamously hard field where the odds are
> _overwhelmingly_ against them if they choose to engineer new solutions.
Developers working in
On Thu, Jan 31, 2008 at 03:46:47PM -0500, Thor Lancelot Simon wrote:
> On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote:
> >
> > Peter sent us his write-up up via private email a few days before he
> > posted it to this list (which got it on Slashdot). I had little time to
> > think a
On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote:
>
> Peter sent us his write-up up via private email a few days before he
> posted it to this list (which got it on Slashdot). I had little time to
> think about the issues he mentioned before his write-up became public.
> When it did, I
On Jan 31, 2008, at 4:07 PM, Guus Sliepen wrote:
I hope that in the future, if you see an application doing something
wrong, you don't immediately give the developers the soundwave
therapy.
The wider point of Peter's writeup -- and of the therapy -- is that
developers working on security t
On Tue, Jan 29, 2008 at 12:26:21PM -0500, Perry E. Metzger wrote:
> Clearly, more people need to know about "Gutmann Soundwave Therapy".
>
> Ivan Krstić <[EMAIL PROTECTED]> writes:
[...]
> > [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238
>
> As it turns out, the central im
On 30 Jan 2008, at 04:26, Perry E. Metzger wrote:
Clearly, more people need to know about "Gutmann Soundwave Therapy".
To this end, I would like to introduce the Gutmann Sound Wave Therapy
Mobile Enlightenment Unit.
http://occasionallyhuman.net/gutmann/
(NSFW if depictions of phallic aud
42 matches
Mail list logo
