On Sat, Jun 28, 2003 at 01:06:03PM -0700, Bill Stewart wrote:
Somebody did an interesting attack on a cable network's customers.
They cracked the cable company's DHCP server, got it to provide a
Connection-specific DNS suffic pointing to a machine they owned,
and also told it to use their DNS
On Tue, Jul 08, 2003 at 02:20:46PM -0700, Eric Murray wrote:
For comparison purposes, I have a copy of an SSLv3/TLS client library
I wrote in 1997. It's 56k of (Intel Linux) code for everything
except RSA. That includes the ASN.1 and X.509 parser.
Implementing the server-specific parts
On Fri, Aug 22, 2003 at 10:00:14AM -0700, Bob Baldwin PlusFive wrote:
Tim,
One issue to consider is whether the system
that includes the PRNG will ever need a FIPS-140-2
rating. For example, people are now working on
a FIPS-140 validation for OpenSSL. If so, then
the generator for
but I haven't had time to get them down in writing;
I'll try to do so before this thread is totally stale...
--
Thor Lancelot Simon [EMAIL PROTECTED]
But as he knew no bad language, he had called him all the names of common
objects that he could think
On Mon, Sep 08, 2003 at 10:49:02AM -0600, Tolga Acar wrote:
On a second thought, that there is no key management algorithm
certified, how would one set up a SSL connection in FIPS mode?
It seems to me that, it is not possible to have a FIPS 140 certified
SSL/TLS session using the OpenSSL's
On Mon, Sep 15, 2003 at 12:57:55PM -0400, Wei Dai wrote:
I think I may have found such a written guidance myself. It's guidance
G.5, dated 8/6/2003, in the latest Implementation Guidance for FIPS
140-2 on NIST's web site:
http://csrc.nist.gov/cryptval/140-1/FIPS1402IG.pdf. This section
On Wed, Oct 01, 2003 at 10:20:53PM +0200, Guus Sliepen wrote:
You clearly formulated what we are doing! We want to keep our crypto as
simple and to the point as necessary for tinc. We also want to
understand it ourselves. Implementing our own authentication protocol
helps us do all that.
On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote:
Thanks everyone for the SSL encouragement. I'm going to have a quick
re-read of Eric's book over the weekend and then start thinking about
what sort of easy to use implementation I could do. I was thinking of
doing a C++
On Fri, Oct 03, 2003 at 04:31:26PM -0400, Tyler Close wrote:
On Thursday 02 October 2003 09:21, Jill Ramonsky wrote:
I was thinking of doing a C++ implentation with classes and
templates and stuff. (By contrast OpenSSL is a C
implementation). Anyone got any thoughts on that?
Given the
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
As far as what OpenSSL does, if you simply abandon outright any hope of
acting as a certificate authority, etc. you can punt a huge amount of
complexity; if you punt SSL, you'll lose quite a bit more
On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
these operations. For example, there is no simple way to do the most
common certificate validation operation
On Thu, Oct 09, 2003 at 07:45:01PM -0700, Bill Frantz wrote:
At 8:18 AM -0700 10/7/03, Rich Salz wrote:
Are you validating the toolchain? (See Ken Thompson's
Turing Aware lecture on trusting trust).
With KeyKOS, we used the argument that since the assembler we were using
was written and
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote:
So what purpose would client certificates address? Almost all of the use
of SSL domain name certs is to hide a credit card number when a consumer
is buying something. There is no requirement for the merchant to
identify and/or
On Wed, Nov 26, 2003 at 02:56:40PM -0800, J Harper wrote:
Great feedback, let me elaborate. I realize that AES is implemented in
hardware for many platforms as well. I'll mention a bit more about our
cryptography architecture below. Do you know why AES is so popular in
embedded? ARC4 is
On Thu, Nov 27, 2003 at 02:45:47PM +1100, Greg Rose wrote:
At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
RC4 is extremely weak for some applications. A block cipher is greatly
preferable.
I'm afraid that I can't agree with this howling logical error. RC4 is
showing its age
On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote:
in the paper.
Roughly speaking:
If I as a White Hat find a bug and then don't tell anyone, there's no
reason to believe it will result in any intrusions. The bug has to
I don't believe that the premise above is valid. To
On Tue, Jun 15, 2004 at 09:37:42PM -0700, Eric Rescorla wrote:
Arnold G. Reinhold [EMAIL PROTECTED] writes:
My other concern with the thesis that finding security holes is a bad
idea is that it treats the Black Hats as a monolithic group. I would
divide them into three categories: ego
On Tue, Jun 21, 2005 at 10:38:42PM -0400, Perry E. Metzger wrote:
Jerrold Leichter [EMAIL PROTECTED] writes:
Usage in first of these may be subject to Bernstein's attack. It's much
harder to see how one could attack a session key in a properly implemented
system the same way. You
such certificates were issued to a party
(identity, AFAIK, still unknown) claiming to be Microsoft? What,
exactly, do you think that party's plans for those certificates
were -- and why, exactly, do you think they were inocuous?
Thor Lancelot Simon[EMAIL
(though I do think it is regrettable that there's a lack
of information on this kind of device capability anywhere public).
--
Thor Lancelot Simon[EMAIL PROTECTED]
We cannot usually in social life pursue a single value or a single moral
aim, untroubled
the vendor refused to
disclose, which I find extremely suspicious. It is possible to get a
DRNG certified without careful analysis of what its input is; I have
personally seen this happen and heard of more instances even after NIST
gave specific guidance to the contrary.
--
Thor Lancelot Simon
and Hifn white papers are good examples of what *every* vendor
should be willing to publically disclose, if their RNG design does not
give them something to hide.
--
Thor Lancelot Simon[EMAIL PROTECTED]
We cannot usually in social life pursue a single
On Tue, Jul 25, 2006 at 03:49:11PM -0600, Anne Lynn Wheeler wrote:
Perry E. Metzger wrote:
EE Times is carrying the following story:
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759
It is about attempts to use cryptography to protect chip designs from
On Thu, Jul 27, 2006 at 08:53:26PM -0600, Anne Lynn Wheeler wrote:
If you treat it as a real security chip (the kind that goes into
smartcards and hardware token) ... it eliminates the significant
post-fab security handling (prior to finished delivery), in part to
assure that counterfeit
On Fri, Jul 28, 2006 at 03:52:55PM -0600, Anne Lynn Wheeler wrote:
Thor Lancelot Simon wrote:
I don't get it. How is there no increase in vulnerability and threat
if a manufacturer of counterfeit / copy chips can simply read the already
generated private key out of a legitimate chip (because
On Mon, Aug 07, 2006 at 05:12:45PM -0700, John Gilmore wrote:
The good news is that CAcert seems to be posistioned for prime time debut,
and you can't beat *Free*. :-)
You certainly can, if slipshod practices end up _costing_
you money.
Has CAcert stopped writing certificates with no DN
On Mon, Sep 11, 2006 at 06:18:06AM +1000, James A. Donald wrote:
3. No one actually uses DNSSEC in the wild.
DNSSEC seems to be not-uncommonly used to secure dynamic updates,
which is not the most common DNS feature in the world but it is not
so uncommon either.
On Wed, Sep 13, 2006 at 10:23:53PM -0400, Vin McLellan wrote:
[... a long message including much of what I can only regard as
outright advertising for RSA, irrelevant to the actual technical
weakness in the SID800 USB token that Hadmut described, and which
Vin's message purportedly disputes.
On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote:
Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.:
On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote:
Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
Anyone have any information on how to develop TPM software?
On Sat, Dec 02, 2006 at 05:15:02PM -0500, John Ioannidis wrote:
On Sat, Dec 02, 2006 at 10:21:57AM -0500, Perry E. Metzger wrote:
Quoting:
The FBI appears to have begun using a novel form of electronic
surveillance in criminal investigations: remotely activating a
mobile
On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote:
In addition I've heard of evaluations where the generator is required to use a
monotonically increasing counter (clock value) as the seed, so you can't just
use the PRNG as a postprocessor for an entropy polling mechanism. Then
On Fri, Jan 26, 2007 at 11:42:58AM -0500, Victor Duchovni wrote:
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
In some cases it may be useful to send the entire chain, one such being
when a
CA re-issues its root with a new expiry date, as Verisign did when its roots
On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote:
Control: The root signing key only controls the contents of the root,
not any level below the root.
That is, of course, false, and presumably is _exactly_ why DHS wants
the root signing key: because, with it, one can sign the
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote:
because, with it, one can sign the appropriate
chain of keys to forge records for any zone one likes.
If the owner of any key signs below their level, it is immediately
visible to anyone doing active checking. The root signing
On Thu, Apr 05, 2007 at 05:30:53PM -0700, Paul Hoffman wrote:
At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote:
You're missing the point. The root just signs itself a new .net key,
and then uses that to sign a new furble.net key, and so forth. No
unusual key use is required.
And you
On Thu, May 24, 2007 at 01:01:03PM -0400, Perry E. Metzger wrote:
Even for https, it costs no more to type in 2048 than 1024 into
your cert generation app the next time a cert expires. The only
potential cost is if you're so close to the performance line that
slower RSA ops will cause you
On Sun, Jul 01, 2007 at 08:38:12AM -0400, Perry E. Metzger wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
(The usage model is that you do the UI portion on the PC, but
perform the actual transaction on the external device, which has a
two-line LCD display for source and destination of
On Mon, Aug 20, 2007 at 11:42:39AM -0400, Peter Thermos wrote:
We can confirm categorically that no malicious activities were attributed
or that our users' security was not, at any point, at risk.
One wonders if it was their attorneys who suggested that they confirm
categorically that x OR y
On Sun, Sep 02, 2007 at 06:26:33PM -0400, Vin McLellan wrote:
At 12:40 PM 9/2/2007, Paul Walker wrote:
I didn't realise the current SecurID tokens had been broken. A quick Google
doesn't show anything, but I'm probably using the wrong terms. Do you have
references for this that I could have
On Mon, Sep 03, 2007 at 04:27:22PM -0400, Vin McLellan wrote:
Thor Lancelot quoted that, and erupted with sanctimonious umbrage:
I think it's important that we know, when flaws in commercial
cryptographic products are being discussed, what the interests of the
parties to the discussion are.
On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote:
| It is, of course, the height of irony that the bug was introduced in
| the very process, and for the very purpose, of attaining FIPS
| compliance!
|
| But also to be expected, because the feature in question is
|
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
It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.
I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
There's a technical/philosophical issue lurking here. We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have
, and the result was still no damned good.
Really? From a cryptographic -- not a political -- point of view, what
exactly is wrong with DNSSEC or WPA?
WPA certainly seems to be quite widely deployed.
--
Thor Lancelot Simon[EMAIL PROTECTED]
My guess
On Sun, Sep 21, 2008 at 01:20:22PM -0400, James Cloos wrote:
IanG == IanG [EMAIL PROTECTED] writes:
IanG Nope, sorry, didn't follow it. What is BOM, SoC, A plug, gerber?
Bill Of Materials -- cost of the raw hardware
System on (a) Chip -- microchip with CPU, RAM, FLASH, etc
USB A Plug
On Mon, Jan 26, 2009 at 02:49:31AM -0500, Ivan Krsti? wrote:
Finally, any idea why the Sect?ra is certified up to Top Secret for
voice but only up to Secret for e-mail? (That is, what are the differing
requirements?)
I know no specific details but strongly suspect the difference in
On Thu, Jan 29, 2009 at 01:22:37PM -0800, John Gilmore wrote:
If it comes from the Trusted Computing Group, you can pretty much
assume that it will make your computer *less* trustworthy. Their idea
of a trusted computer is one that random unrelated third parties can
trust to subvert the will
On Fri, Jan 30, 2009 at 04:08:07PM -0800, John Gilmore wrote:
The theory that we should build good and useful tools capable of
monopoly and totalitarianism, but use social mechanisms to prevent
them from being used for that purpose, strikes me as naive.
Okay. In that case, please, explain
On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:
Given that, when I looked a couple of years ago, TPM support for
public/private-key stuff was rather hit-and-miss and in some cases seemed to
be entirely absent (so you could use the TPM to wrap and unwrap stored private
keys
But
)
No, no there's not. In fact, I solicited information here about crypto
accellerators with onboard persistent key memory (secure key storage)
about two years ago and got basically no responses except pointers to
the same old, discontinued or obsolete products I was trying to replace.
--
Thor Lancelot
common feature on accellerators targetted at
the SSL/IPsec market. That appears to no longer be the case.
--
Thor Lancelot Simont...@rek.tjls.com
Even experienced UNIX users occasionally enter rm *.* at the UNIX
prompt only to realize too late
I don't have any details of how it works (and I don't know how hard
it would be to get Broadcom to cough them up -- they seem better about
this lately than they used to be) but looking at the bcm586x product
announcement, I see they added onboard key storage.
--
Thor Lancelot Simon
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
In order to roll out a new crypto algorithm, you have to roll
On Tue, Jul 13, 2010 at 05:46:36PM +1200, Peter Gutmann wrote:
Paul Wouters p...@xelerance.com writes:
Which is what you should do anyway, in case of a hardware failure. I
know the Linux intel-rng and amd-rng used to produce nice series of zeros.
Do you have any more details on this? Was
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote:
I think you'll have to agree that unlike history, which starts out as
tragedy and replays itself as farce, PKI has always been farce over the
centuries. It might actually end up as tragedy, but so far so good. I'm
sure that if we
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote:
The big drawback is that those who want to follow NIST's
recommendations to migrate to 2048-bit keys will be returning to
the 2005-era overhead. Dan Kaminsky provided some benchmarks in a
different thread on this
On Fri, Aug 27, 2010 at 07:20:06PM +1200, Peter Gutmann wrote:
No. If you choose your eval lab carefully you can sneak in a TRNG somewhere
as input to your PRNG, but you can't get a TRNG certified, and if you're
unlucky you won't be allowed to use a TRNG at all.
I am surprised you'd have
On Tue, Sep 14, 2010 at 08:14:59AM -0700, Paul Hoffman wrote:
At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for
someone else:
This suggests to me that even if NIST is correct that 2048 bit RSA
keys are the reasonable the minimum for new deployments after 2010,
much
Project http://www.openssl.org
Development Mailing List openssl-...@openssl.org
Automated List Manager majord...@openssl.org
- End forwarded message -
--
Thor Lancelot Simont
On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
Thor Lancelot Simon writes:
a significant net loss of security, since the huge increase in computation
required will delay or prevent the deployment of SSL everywhere.
That would only happen if we (as security experts) allowed
On Thu, Sep 30, 2010 at 01:36:47PM -0400, Paul Wouters wrote:
[I wrote]:
Also, consider devices such as deep-inspection firewalls or application
traffic managers which must by their nature offload SSL processing in
order to inspect and possibly modify data
You mean it will be harder for MITM
On Wed, Oct 06, 2010 at 01:32:00PM -0500, Matt Crawford wrote:
That is, if your CA key size is smaller, stop signing with it.
You may have missed the next sentence of Mozilla's statement:
All CAs should stop issuing intermediate and end-entity certificates with
RSA key size smaller than 2048
On Fri, Sep 06, 2013 at 07:53:42PM -0400, Marcus D. Leech wrote:
One wonders why they weren't already using link encryption systems?
One wonders whether, if what we read around here lately is much guide,
they still believe they can get link encryption systems that are
robust against the only
On Thu, Sep 12, 2013 at 11:00:47AM -0400, Perry E. Metzger wrote:
In addition to getting CPU makers to always include such things,
however, a second vital problem is how to gain trust that such RNGs
are good -- both that a particular unit isn't subject to a hardware
defect and that the
65 matches
Mail list logo
