Re: Haskell crypto

2005-11-30 Thread Alexander Klimov
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. http://www.haskell.org/aboutHaskell.html Original Message I just recently stepped into open source cryptography

Re: ISAKMP flaws?

2005-11-30 Thread bear
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 that

Re: ISAKMP flaws?

2005-11-30 Thread Peter Gutmann
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 guess that's one

Re: Haskell crypto

2005-11-30 Thread Nathan Loofbourrow
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

Re: ISAKMP flaws?

2005-11-30 Thread Peter Gutmann
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 be

Anon_Terminology_v0.24

2005-11-30 Thread R. A. Hettinga
--- 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

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

2005-11-30 Thread Anton Stiglic
-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

Re: timing attack countermeasures (nonrandom but unpredictable delays)

2005-11-30 Thread Travis H.
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: timing attack countermeasures (nonrandom but unpredictable de lays)

2005-11-30 Thread Travis H.
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,x)

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

2005-11-30 Thread Joseph Ashwood
- 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 applied.

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

2005-11-30 Thread leichter_jerrold
| 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

Session Key Negotiation

2005-11-30 Thread Will Morton
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

Re: ISAKMP flaws?

2005-11-30 Thread Bill Stewart
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

Web Browser Developers Work Together on Security

2005-11-30 Thread Jason Holt
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

Web Browser Developers Work Together on Security

2005-11-30 Thread Aram Perez
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

[Clips] Cyberterror 'overhyped,' security guru says

2005-11-30 Thread R. A. Hettinga
--- 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

Broken SSL domain name trust model

2005-11-30 Thread Anne Lynn Wheeler
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

Encryption using password-derived keys

2005-11-30 Thread Jack Lloyd
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

Call for papers -- IS-TSPQ 2006

2005-11-30 Thread Ed Gerck
== CALL FOR PAPERS First International Workshop on Interoperability Solutions to Trust, Security, Policies and QoS for Enhanced Enterprise Systems

Matt Blaze finds flaws in FBI wiretap equipment

2005-11-30 Thread Perry E. Metzger
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

ADMIN: microsoft.com subscribers may be unsubscribed soon

2005-11-30 Thread Perry E. Metzger
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 Your e-mail was rejected by an anti-spam content filter on gateway

Re: Session Key Negotiation

2005-11-30 Thread Eric Rescorla
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 secret'

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

2005-11-30 Thread Amir Herzberg
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` name of CA - like TrustBar. They do not yet implement some of our other mechanisms,