Re: Session Key Negotiation

Will Morton <[EMAIL PROTECTED]> writes: > I am designing a transport-layer encryption protocol, and obviously wish > to use as much existing knowledge as possible, in particular TLS, which > AFAICT seems to be the state of the art. > > In TLS/SSL, the client and the server negotiate a 'master secre

ADMIN: microsoft.com subscribers may be unsubscribed soon

About half the messages to cryptography are being rejected by microsoft.com's anti-spam content filter, with messages like this: <[EMAIL PROTECTED]>: host maila.microsoft.com[131.107.3.125] said: 550 5.7.1 (in reply to end of DATA command) I've been manually preventing the Microsoft address

Matt Blaze finds flaws in FBI wiretap equipment

New York Times article: Security Flaw Allows Wiretaps to Be Evaded, Study Finds By JOHN SCHWARTZ and JOHN MARKOFF Published: November 30, 2005 The technology used for decades by law enforcement agents to wiretap telephones has a security flaw that allows the person being wiretapp

Call for papers -- IS-TSPQ 2006

== CALL FOR PAPERS First International Workshop on Interoperability Solutions to Trust, Security, Policies and QoS for Enhanced Enterprise Systems

Encryption using password-derived keys

The basic scenario I'm looking at is encrypting some data using a password-derived key (using PBKDF2 with sane salt sizes and iteration counts). I am not sure if what I'm doing is sound practice or just pointless overengineering and wanted to get a sanity check. My inclination is to use the PBKDF

Broken SSL domain name trust model

so this is (another in long series of) post about SSL domain name trust model http://www.garlic.com/~lynn/2005t.html#34 basically, there was suppose to be a binding between the URL the user typed in, the domain name in the URL, the domain name in the digital certificate, the public key in the digi

[Clips] Cyberterror 'overhyped,' security guru says

--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Thu, 24 Nov 2005 14:08:41 -0500 To: Philodox Clips List <[EMAIL PROTECTED]> From: "R. A. Hettinga" <[EMAIL PROTECTED]> Subject: [Clips] Cyberterror 'overhyped,' security guru says Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PRO

`Identified by` technique of TrustBar adopted by IE, other browsers...

IE 7 implements some of TrustBar and FF improvements to security indicators. Specifically, they now color-code the location bar and added, in SSL/TLS pages, the name of the site and the `Identified by` - like TrustBar. They do not yet implement some of our other mechanisms, including the pet

Web Browser Developers Work Together on Security

Core KDE developer George Staikos recently hosted a meeting of the security developers from the leading web browsers. The aim was to come up with future plans to combat the security risks posed by phishing, ageing encryption ciphers and inconsistent SSL Certificate practise. Read on for Geo

Web Browser Developers Work Together on Security

http://dot.kde.org/1132619164/ Core KDE developer George Staikos recently hosted a meeting of the security developers from the leading web browsers. The aim was to come up with future plans to combat the security risks posed by phishing, ageing encryption ciphers and inconsistent SSL Certifi

Re: "ISAKMP" flaws?

At 06:56 PM 11/18/2005, William Allen Simpson wrote: | tromped around the office singing, "Every bit is sacred / Every bit | is great / When a bit is wasted / Phil gets quite irate." | Consider this to be one of the prime things to correct. Personally, | I think that numbers should never (

Session Key Negotiation

I am designing a transport-layer encryption protocol, and obviously wish to use as much existing knowledge as possible, in particular TLS, which AFAICT seems to be the state of the art. In TLS/SSL, the client and the server negotiate a 'master secret' value which is passed through a PRNG and used

Re: timing attack countermeasures (nonrandom but unpredictable de lays)

| > Why do you need to separate f from f+d? The attack is based on a timing | > variation that is a function of k and x, that's all. Think of it this way: | > Your implementation with the new d(k,x) added in is indistinguishable, in | > externally visible behavior, from a *different* implementati

Re: Fermat's primality test vs. Miller-Rabin

- Original Message - From: "Anton Stiglic" <[EMAIL PROTECTED]> Subject: RE: Fermat's primality test vs. Miller-Rabin -Original Message- From: [Joseph Ashwood] Subject: Re: Fermat's primality test vs. Miller-Rabin I think much of the problem is the way the number is being appli

Re: timing attack countermeasures (nonrandom but unpredictable de lays)

> Why do you need to separate f from f+d? The attack is based on a timing > variation that is a function of k and x, that's all. Think of it this way: > Your implementation with the new d(k,x) added in is indistinguishable, in > externally visible behavior, from a *different* implementation f'(k,

Re: timing attack countermeasures (nonrandom but unpredictable delays)

Good points all. I was implicitly assuming that d(k, x) is related to the timing of f(k,x) -- tailored to the algorithm(s) used, and that the attacker cannot control k. Actually the idea was to have k merely provide a unique function d_k(x) for each host. > The only way to avoid this is to make

RE: Fermat's primality test vs. Miller-Rabin

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Ashwood Sent: November 18, 2005 3:18 AM To: cryptography@metzdowd.com Subject: Re: Fermat's primality test vs. Miller-Rabin >> Look at table 4.3 of the Handbook of >> applied cryptography: for t = 1

Anon_Terminology_v0.24

--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Mon, 21 Nov 2005 12:14:40 +0100 From: Andreas Pfitzmann <[EMAIL PROTECTED]> To: undisclosed-recipients: ; Subject: Anon_Terminology_v0.24 Sender: [EMAIL PROTECTED] Hi all, Marit and myself are happy to announce Anonymi

from the bad idea department

Steve Gibon is now offering a "GRC's Ultra High Security Password Generator" -- a web page that provides you with "totally random" data in 3 formats: 64 hex digits, 63 printable characters, or 63 alphanumerics. The page suggests using them for passwords, WEP and WPA, VPN shared secrets, and more.

Re: "ISAKMP" flaws?

Tero Kivinen <[EMAIL PROTECTED]> writes: >If I understood correctly the tools they used now did generate specific hand- >crafted packets having all kind of wierd error cases. When testing with the >crypto protocols the problem is that you also need to do the actual crypto, >key exchangement etc to

Re: Haskell crypto

Haskell is a strongly typed functional language with type inference, much like ML; its key difference from ML is that is purely functional, allowing it to use lazy evaluation. I'm not sure how that illuminates the original message, except to note that I agree that coding in Haskell is quite fun a

Re: "ISAKMP" flaws?

bear <[EMAIL PROTECTED]> writes: >On Sat, 19 Nov 2005, Peter Gutmann wrote: >>- The remaining user base replaced it with on-demand access to network >> engineers who come in and set up their hardware and/or software for them and >> hand-carry the keys from one endpoint to the other. >> >> I gues

Re: "ISAKMP" flaws?

On Sat, 19 Nov 2005, Peter Gutmann wrote: >- The remaining user base replaced it with on-demand access to network > engineers who come in and set up their hardware and/or software for them and > hand-carry the keys from one endpoint to the other. > > I guess that's one key management model th

Re: Haskell crypto

On Sat, 19 Nov 2005, Ian G wrote: > Someone mailed me with this question, anyone know > anything about Haskell? It is a *purely* functional programming language. > Original Message > > I just recently stepped into open source cryptogra