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 attacker gets
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.
This is
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
| - 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 feature
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
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
| 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.
|
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
| substreams,
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 as a
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
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
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 where
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 key
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
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,
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
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
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
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:
[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 vendors
--
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
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 odds are
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 expert
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
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 look
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 packets
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 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 about the
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
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 configure.
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 does
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
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 image
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
Clearly, more people need to know about Gutmann Soundwave Therapy.
Ivan Krstić [EMAIL PROTECTED] writes:
[...] but nowadays I ask that they Google the famous Gutmann Sound
Wave Therapy[0] and mail me afterwards.
I've never heard back.
[0] Last paragraph, http://diswww.mit.edu/bloom
35 matches
Mail list logo
