On Fri, Oct 08, 2010 at 04:27:57PM -0400, Perry E. Metzger wrote:
> I have a client with the following problem. They would like to
> encrypt all of their Windows workstation drives, but if they do that,
> the machines require manual intervention to enter a key on every
> reboot. Why is this a prob
On Wed, Oct 06, 2010 at 04:52:46PM +1300, Peter Gutmann wrote:
> From https://wiki.mozilla.org/CA:MD5and1024:
>
> December 31, 2010 - CAs should stop issuing intermediate and end-entity
> certificates from roots with RSA key sizes smaller than 2048 bits [0]. All
> CAs should stop issuing in
On Thu, Sep 30, 2010 at 01:32:38PM -0400, Thor Lancelot Simon wrote:
> On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
> >
> > One solution would be to use 2048-bit 4-prime RSA. It would maintain the
> > security of RSA-2048, enable the reusing of the modular arithmetic units
> > of
On Tue, Sep 07, 2010 at 10:22:57PM -0400, Jerry Leichter wrote:
> But there isn't actually such a thing as classical thermodynamical
> randomness! Classical physics is fully deterministic. Thermodynamics uses
> a probabilistic model as a way to deal with situations where the necessary
> infor
On Fri, Sep 03, 2010 at 07:16:00PM +0300, Sampo Syreeni wrote:
> On 2010-09-02, travis+ml-cryptogra...@subspacefield.org wrote:
>
>> I hear that NIST Key Mgmt guideline (SP 800-57) suggests that the RSA key
>> size equivalent to a 256 bit symmetric key is roughly 15360 bits. I
>> haven't actuall
On Tue, Apr 20, 2010 at 08:58:25PM -0400, Thierry Moreau wrote:
> The DNS root may be qualified as a "high valued" zone, but I made the
> effort to put in writing some elements of a "risk analysis" (I have an
> aversion for this notion as I build *IT*controls* and the consultants are
> hired to
On Tue, Nov 17, 2009 at 01:35:12AM -, John Levine wrote:
> > So should or should not an embedded system have a remote management
> > interface?
>
> In this case, heck, no. The whole point of this thing is that it is
> NOT remotely programmable to keep malware out.
Which is perhaps why it is
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
> Anyone care to give a "layman's" explanation of the attack? The
> explanations I have seen assume a detailed knowledge of the way TLS/SSL
> handle re-negotiation,
The re-negotiation handshake does not *commit* both parties in the
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote:
> I'll point out that in the midst of several current discussions, the
> news of the TLS protocol bug has gone almost unnoticed, even though it
> is by far the most interesting news of recent months.
Not entirely unnoticed:
ht
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
> > Given that they are attempted to optimize for minimal packet size, the
> > choice of RSA for signatures actually seems quite bizarre.
> Each of these records is cached on the client side, with a very long
> timeout (e.g. at least a
ot;simplest", but (as pointed out upthread) Galois extensions
of Z_2 are typically more convenient computationally.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Secur
ecimal weren't widely available when came up with this
> scheme back in 1979.
An algorithm is not the same an implementation. There was no Java back
then either, and people still somehow wrote working code in '79.
--
/"\ ASCII RIBBON NOTICE: If received in error,
On Tue, Sep 29, 2009 at 10:51:33PM -0700, Jacob Appelbaum wrote:
> It's been long enough that everyone should be patched for this awesome
> class of bugs. This certificate and corresponding private key should
> help people test fairly obscure software or software they've written
> themselves. I ho
On Wed, Jul 01, 2009 at 11:03:13AM -0400, Adam Shostack wrote:
> On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote:
> | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote:
> | > This would be great if LoginWindow.app didn't store your unencrypted
> | > login and passwor
On Sun, Jun 07, 2009 at 05:41:00PM -0700, Greg Perry wrote:
> The significance of this method is the ability to determine any
> properties of p and q from a simple operation to n.
To be blunt, I see no significance of any kind...
You have observed that unless N is divisible by 3, p and q are bot
On Sun, Jun 07, 2009 at 05:10:30PM +0100, Ben Laurie wrote:
> Paul Hoffman wrote:
> > At 8:07 PM -0700 6/5/09, Greg Perry wrote:
> >> Greetings list members,
> >>
> >> I have published a unique factoring method related to Pollard's Rho
> >> that is published here:
> >>
> >> http://blog.liveammo.
On Fri, Jun 05, 2009 at 08:07:21PM -0700, Greg Perry wrote:
> I have published a unique factoring method related to Pollard's Rho that
> is published here:
>
> http://blog.liveammo.com/2009/06/factoring-fun/
Several aspects of the RSA encryption algorithm can be attacked:
attacks against
On Mon, May 11, 2009 at 02:16:45PM -0400, Roland Dowdeswell wrote:
> >In any case, there are obvious, well-understood solutions here: Use
> >counter mode, which propagates changes by a single block of the
> >cryptosystem. Or use any other stream cipher mode. (An interesting
> >question is
On Thu, Apr 30, 2009 at 11:07:31PM -0400, Perry E. Metzger wrote:
>
> Greg Rose writes:
> >> This is a very important result. The need to transition from SHA-1
> >> is no longer theoretical.
> >
> > It already wasn't theoretical... if you know what I mean. The writing
> > has been on the wall si
ON_NUMBER 0x0090809fL
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan
On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote:
> The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256
> mandatory), so you can send a SHA-256 certificate to clients that
> indicate they support TLS 1.2 or later. You'd still need some other
> certificate for interop
tart to address the issue now. SHA-1 will be with
us well after 2010. New applications written in 2010 will ideally
support SHA-2, but SHA-1 will probably still be the default digest
in many applications through 2013 or 2015.
--
/"\ ASCII RIBBON NOTICE: If received in er
On Thu, Jan 08, 2009 at 06:23:47PM -0600, Dustin D. Trammell wrote:
> Nearly everything I've seen regarding the proposed solutions to this
> attack have involved migration to SHA-1. SHA-1 is scheduled to be
> decertified by NIST in 2010, and NIST has already recommended[1] moving
> away from SHA-
On Mon, Dec 08, 2008 at 08:53:18PM -0800, Jon Callas wrote:
> >In the NBC TV episode of /Chuck/ a couple of weeks ago, the NSA
> >cracked
> >"a 512-bit AES cipher" on a flash drive "trying every possible key".
> >"Could be hours, could be days." (Only minutes in TV land.)
> >
> >http://www.nbc.
I am considering adding TLS Server Name Indication support in the Postfix
SMTP server and client. I am puzzled by the exceedingly terse description
of the semantics of the HostName sent in the SNI extension:
http://tools.ietf.org/html/rfc4366#section-3.1
If the hostname labels contain
On Tue, Sep 16, 2008 at 09:01:51PM +0200, Weger, B.M.M. de wrote:
> There's a new biggest known RSA modulus.
> It is (in hexadecimal notation):
>
> FF...(total of 9289166 F's)...FFDFF...(total of 1488985
> F's)...FF800...(total of 9289165 0's)...001
>
> It is guaranteed to be the product of two
On Mon, Jul 21, 2008 at 12:03:50PM -0400, Victor Duchovni wrote:
> On Sun, Jul 20, 2008 at 04:14:33PM -0600, Matt Ball wrote:
>
> > >From a little bit of off-line discussion, I think I've got a restatement of
> > the problem that is more suitable to those w
.
This matrix has a minimum polynomial of degree at most 96.
A**96 = c_95 * A**95 + c_94 * A**94 ... + c_0 * I
The 32-bit output then also satisfies:
x_96 = c_95 * x_95 + c_94 * x_94 ... + c_0
for the same coefficients.
--
/"\ ASCII RIBBON NOTICE: If re
most certainly a generalization of:
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-4.3
specifically the second paragraph the mentions the "Birthday Attack". The
assumptions of that paragraph can be relaxed in a natural way to broaden
the scope of the attack.
snake oil.
> http://www.foxbusiness.com/story/hackers-hell-privacy-compromised/
This reads like a pump'n'dump stock scam.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender.
On Fri, Jul 04, 2008 at 04:04:11PM -0700, Allen wrote:
> Interesting tidbit:
>
> http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=121516308313743148197&block=
>
> "Nick Ogden, a Briton who launched one of the world's first
> e-commerce processors in 1994, has developed a system fo
On Tue, Jun 03, 2008 at 04:37:20PM -0400, Eric Cronin wrote:
>
> On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote:
>
> >Depending on the level of protection you want, you could just add a
> >script to your .forward to encrypt your email before delivery using
> >PGP/GPG. However, this will leave the
your IMAP client, if it can cache/index
decrypted content.
Not much demand for this yet, so I don't expect mature offerings any
time soon. We'd have to build a boutique service for cipher-punks.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN
volved in that step, or it could just
negotiate the new KEK using the current KEK. There is not in practice
any need for a PKI in this context, it looks rather a lot more like
Kerberos than PKI.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor D
On Thu, May 29, 2008 at 10:05:17AM -0400, Derek Atkins wrote:
> Arshad Noor <[EMAIL PROTECTED]> writes:
>
> > Even if RIM does not have the device keys, in order to share encrypted
> > data with applications on the RIM server, the device must share a session
> > key with the server; must it not?
On Tue, May 27, 2008 at 08:08:11PM +0100, Dave Korn wrote:
> Well spotted. Yes, I guess that's what Jim Youll was asking. And I
> should have said "seemingly-contradictory". This is, of course, what I
> meant by "marketeering": when someone asks if your service is insecure and
> interceptable
On Tue, May 13, 2008 at 02:10:45PM +0100, Ben Laurie wrote:
> [Moderator's note: A quick reminder: please use ASCII except if you
> need Unicode to spell your name right. Microsoft's proprietary quote
> marks are not a standard and don't look right on non-Microsoft
> displays. I edited them out of
signed to run in (realistic)
bounded memory (no "fork: out of memory").
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTM
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:
> >- With the upcoming EECDH support, users don't choose curves
> >directly, they again choose a security grade, and the correspnding
> >curves are configurable via parameters they are not expected to
> >ever look at or
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
> I believe that those who supply security products have a responsibility
> to consider the knowledge, experience, and tendencies of their likely
> users to the greatest extent to which they're able, and supply products
> which w
Expectations of privacy at work vary by jurisdiction and industry. In
the US, and say in the financial services industry, any such expectations
are groundless (IANAL).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destro
less the A5 attacks crack a cipher with ~95
bits security, the estimate is grossly wrong.
If (generously) A5 is 64 bits of work, AES is ~20 orders of magnitude
stronger.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and no
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote:
> Actually there are already companies doing something like this
Which ones do you think are doing a decent job of this?
> but they've
> run into a problem that no-one has ever considered so far: The GTCYM needs a
> (relatively) high
On Sun, Mar 30, 2008 at 05:13:07PM -0400, Ivan Krsti?? wrote:
> That's a brute force search. If your convergence key, instead of being
> a simple file hash, is obtained through a deterministic but
> computationally expensive function such as PBKDF2 (or the OpenBSD
> bcrypt, etc), then step 3
es easy to forget that not all the world is OpenSSL...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or
browser APIs for this are completely different and rather
minimally documented. The interfaces are not portable between browsers,
... It's a mess.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >While Firefox should ideally be developing and testing PSK now, without
> >stable libraries to use in servers and browsers, we can't yet expect anythi
h level of the stable release).
While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect
anything to be released.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Vic
On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds
> >round-trips to SSL warrants some evidence (it is very temping to express
On Thu, Jan 31, 2008 at 02:28:30PM -0500, Anne & Lynn Wheeler wrote:
> TCP requires minimum of seven message exchange for reliable transport
> VMTP (rfc 1045) got that down to minimum of five messages, and XTP
> then
> got it down to three messages minimum for reliable transport (disclaimer
not DNS. Sure if
you can guarantee a single packet response to a single packet request,
TCP is not the answer. Otherwise, claiming that SSL is less efficient
over TCP smacks of arrogance.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni
mechanism
selection:
http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only
http://www.postfix.org/postconf.5.html#smtp_sasl_tls_security_options
which is highly suggestive of using TLS to protect plain-text passwords
in flight.
--
/"\ ASCII RIBBON NOTICE: If receiv
On Tue, Jan 08, 2008 at 07:43:58AM +0800, Ian Farquhar (ifarquha) wrote:
> I've been having this problem for years (my mother's maiden name is,
> indeed, four characters long). It's often rejected as too short, yet
> I'm forced to enter it. I do the workaround of entering it twice, but
> then ha
e, and morphed. If well documented,
the developers can learn by reading the sample code, and training can
be based around the approaches taken in the show-case systems.
When I hear developers demanding "security APIs" I pretend to be deaf...
--
/"\ ASCII RIBBON
gs are just as likely in closed-source software and are less
likely to be discovered.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ H
Via Slashdot:
http://www.ncl.ac.uk/press.office/press.release/content.phtml?ref=1193215475
An interesting variant on biometrics, can't easily be reproduced with
pieces of one's body separated from the whole, and involves in part
something remembered. No hard numbers were provided on FP/FN rates.
conclude that the election data has
as a result less relevance and purpose.
In our physical analogy, heat is replaced with "trust/relevance/purpose".
One can transfer this "heat" from the election to a technology or from a
technology an election, always in the expected direction.
--
On Thu, Oct 04, 2007 at 02:37:21PM -0500, [EMAIL PROTECTED] wrote:
> http://it.slashdot.org/article.pl?sid=07/10/04/1639224&from=rss
>
> Interesting quote:
>
> Jon Callas, CTO and CSO of PGP Corp., responded that this [previously
> undocumented] feature was required by unnamed customers and that
ve not looked at IKE closely enough to comment on whether small
subgroups are a concern in that context.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not w
NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
tency is too high... Simulations of
supernova explosions or aircraft wing dynamics probably don't easily
scale on Storm...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security,
agencies, but
if I were a budget director I would spend the money elsewhere...
> I am most curious as to the legal issue that came up regarding QKD.
Indeed, what was the legal question that got us here?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN
ful for key distribution. It remains (charitably) "fiction".
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MA
e.
Suppose I install a fake subway entrace, and MITM all the interactions
between the victim's card and the real turnstile where I have a card that
proxies the victims interactions with the fake terminal. Is the system
still secure? Likely not, I would bet The threat model was card forgery,
what sense? Did I miss reading about the part of QKD that
addresses MITM (just as plausible IMHO with fixed circuits as passive
eavesdropping)?
Once QKD is augmented with authentication to address MITM, the "Q"
seems entirely irrelevant.
--
/"\ ASCII RIBBON NOT
s reality.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
ing, the technology is not sufficient, merely necessary...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ H
uot;Corporate" or "Personal" BlackBerry devices?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stan
DNS would be vastly better,
but not only are we not getting there, we don't even seem to be going
there at all.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender.
On Wed, May 23, 2007 at 06:34:26PM +0200, Florian Weimer wrote:
> * Victor Duchovni:
>
> >> That's good of you not to expect it, given that zero of the major CAs
> >> seem to support ECC certs today, and even if they did, those certs
> >> would not work i
On Wed, May 23, 2007 at 02:45:49PM +1200, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >As 1024 RSA keys are not a major risk *today*,
>
> I would go further and say that for most applications of PKCs/PKI today, 1024-
> bit RSA keys are
s a new "fingerprint" security level, where
the SMTP client verifies the server certificate by its md5, sha1, or
SHA256/384/512 fingerprint. (No support for web-of-trust, one step
at a time).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victo
two certs (RSA and ECC) for the same subject name(s),
this also may significantly impede migration.
With EECDH one can use ECDH handshakes signed with RSA keys, but that
does not really address any looming demise of 1024 bit RSA.
--
/"\ ASCII RIBBON NOTICE: If received in err
IVs.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confide
ams?
This is a protocol question, not an algorithm question, so you need a
security review of the protocol (which you have not described).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT
l enough to warrant the bad press. Time will tell
of course, but my instinct is that this is story is only interesting to
the extent that it makes the feared scenario less likely, so though I
don't find it a credible threat, the publicity may help to avert any
silliness from coming to pass.
reason for the DHS to
have it, so I am assuming that they won't have it, and perhaps the story
is the result of confusion/incomptence somewhere.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AG
#x27;t want to follow in the footsteps of Randal
L. Schwartz, it is sadly best to stay ignorant of such matters...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Se
On Thu, Feb 15, 2007 at 11:36:35AM -0500, Victor Duchovni wrote:
> On Thu, Feb 15, 2007 at 10:10:21AM -0500, Leichter, Jerry wrote:
>
> > Meanwhile, the next generation of users is growing up on the immediacy
> > of IM and text messaging. Mail is ... so 20th century.
>
il is not shrinking in significance here.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >What I don't understand is how the old (finally expired) root helps to
> >validate the new unexpired root, when a verifier has the old root and the
>
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >What I don't understand is how the old (finally expired) root helps to
> >validate the new unexpired root, when a verifier has the old root and the
>
and is how
the old (finally expired) root helps to validate the new unexpired root,
when a verifier has the old root and the server presents the new root
in its trust chain.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Wouldn't the old root also (until it actually expires) verify any
> >certificates signed by the new root? If so, why does a server need to send
>
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Generally it is enough for a TLS server or client to present its own
> >certificate and all *intermediate* CA certificates, sending the root CA cert
> &
t the factor 2^36, but it sure makes a big difference.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \
r, ...) into a single file and set that as the Server
Cert file, not the CA file.
Please take any further questions to openssl-users@openssl.org (via
[EMAIL PROTECTED]).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy a
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >It took reading the code to determine the following:
> >
> >- ASN.1 Strings extracted from X.509v3 certs are not validated for
> >con
at I can make sure that my code is a correct use of the interface,
that I am not making unfounded assumptions, and there are no obvious bugs
in the part of the library that I am reviewing.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovn
On Wed, Jan 10, 2007 at 06:31:21PM -0500, Steven M. Bellovin wrote:
> I just stumbled on a web site that strongly believes in crypto --
> *everything* on the site is protected by https. If you go there via
> http, you receive a Redirect. The site? www.cia.gov:
>
> $ telnet www.cia.gov 80
> Try
caches on both sides only does one SSL handshake per
cache TTL and then just bulk crypto for many deliveries that reuse the
cached SSL session.
So what is your load like?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please des
On Wed, Oct 18, 2006 at 12:00:41AM -0400, Victor Duchovni wrote:
> Hash functions are supposed to be pseudo-random. For a 160 bit hash In
> an input set of 2^80 elements we should expect to find a collision...
>
> If we iterate from a random starting point we expect to enter a cycle
alf of the inputs outside a cycle and half
inside a cycle. None of this should lead to any apparent weakness after
a modest number of iterations.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST
at least as trained today,
but it is not likely possible to design a training program that will
a preponderance all strong defensive programmers).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use
at work *together* "securely" in
a reasonable fashion, or are we still building the tower of Babel (now
in software). A more trustworthy DNS would IMHO be a good foundation.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please
onses.
Ultimately, to close similar security issues in many other protocols,
we need a secure DNS, but I am somewhat pessimistic about the likelihood
of this happening soon.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please de
On Sun, May 14, 2006 at 07:56:17PM -0500, Travis H. wrote:
> On 5/14/06, Victor Duchovni <[EMAIL PROTECTED]> wrote:
> >Security is fragile. Deviating from well understood primitives may be
> >good research, but is not good engineering. Especially fragile are:
>
> Poin
pitfalls.
TLS (available via OpenSSL) provides integrity and authentication, any
reason to re-invent the wheel? It took multiple iterations of design
improvements to get TLS right, even though it was designed by experts.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN
1 - 100 of 182 matches
Mail list logo
