James A. Donald wrote:
--
On 12 Jun 2003 at 16:25, Steve Schear wrote:
http://www.acros.si/papers/session_fixation.pdf
Wow.
This flaw is massive, and the biggest villain is the server
side code created for Apache.
When you login to your bank, your e-gold account, your
Ed Gerck wrote:
From your URLs:
The browser verifies that the fingerprint in the URL matches the public key
provided by the visited site. Certificates and Certificate Authorities are
unnecessary.
Spoofing? Man-in-the-middle? Revocation?
Also, in general, we find that one reference
Joshua Hill wrote:
On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote:
In fact they wouldn't even validate Crypto++ as a
static library despite an earlier verbal agreement that a static
library was ok. It had to be turned into a DLL at the last moment (i.e.
during the review phase).
Wei Dai wrote:
On Fri, Sep 05, 2003 at 04:15:22PM -0400, Anton Stiglic wrote:
You are correct, I just saw Crypto++ in the list of FIPS 140 validated
modules:
http://csrc.nist.gov/cryptval/140-1/140val-all.htm
It is the latest entry, added today.
Congratulations to Wei Dai!
Thanks! Also
Eric Rescorla wrote:
Incidentally, when designing SHTTP we envisioned that credit
transactions would be done with signatures. I would say that
the Netscape guys were right in believing that confidentiality
for the CC number was good enough.
I don't think so. One of the things I'm running into
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. As far as the
programming interface goes, I'd read Eric's book
[EMAIL PROTECTED] wrote:
On Thu, 2 Oct 2003, Thor Lancelot Simon wrote:
1) Creates a socket-like connection object
2) Allows configuration of the expected identity of the party at the other
end, and, optionally, parameters like acceptable cipher suite
3) Connects, returning error if the
Jill Ramonsky wrote:
Too late. I've already started. Besides which, posts on this group
suggest that there is a demand for such a toolkit.
I think there's demand in the sense that there's demand for free
lunches. People would like the inherent complexity to go away, because
they can see that
Thor Lancelot Simon wrote:
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
Peter Clay wrote:
On Thu, 9 Oct 2003, Peter Gutmann wrote:
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
Since I'm sure Perry will eventually get tired of VPNs, before he does I
should announce that I have, at the request of several participants in
the recent discussions, set up a list for VPN theory discussion. It is
currently unmoderated, though I reserve the option to change that if
warranted.
[EMAIL PROTECTED] wrote:
Sender's Algorithm
SymmetricKey1 = 3DES_IV1, 3DES_Key1
Cipher1 = 3DES_Encrypt(message)
Digest = SHA1(message)
RSA_Key1 = RSA_Private_Encrypt(Digest || 3DES_Key1)
SymmetricKey2 = 3DES_IV2, 3DES_Key2
Cipher2 = 3DES_Encrypt(Cipher1)
RSA_Key2 = RSA_Public_Encrypt(3DES_Key2)
Carl Ellison wrote:
It is an advantage for a TCPA-equipped platform, IMHO. Smart cards cost
money. Therefore, I am likely to have at most 1.
If I glance quickly through my wallet, I find 7 smartcards (all credit
cards). Plus the one in my phone makes 8. So, run that at most 1
argument past me
Carl Ellison wrote:
We see here a difference between your and my sides of the Atlantic. Here in
the US, almost no one has a smart card.
Of those cards you carry, how many are capable of doing public key
operations? A simple memory smartcard doesn't count for what we were
talking about.
I don't
Ian Grigg wrote:
What is the source of the acronym PAIN?
Lynn said:
... A security taxonomy, PAIN:
* privacy (aka thinks like encryption)
* authentication (origin)
* integrity (contents)
* non-repudiation
I.e., its provenance?
Google shows only a few hits, indicating
it is not widespread.
bear wrote:
I really don't care if anyone *else* trusts my system; as
far as I'm concerned, their secrets should not be on my
system in the first place, any more than my secrets should
be on theirs.
The problem is that their secrets are Snow White, or the latest Oasis
album. You want them on your
Bill Frantz wrote:
One should note that TCPA is designed to store its data (encrypted) in the
standard file system, so standard backup and restore techniques can be
used.
Only if your box doesn't die.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no
Ian Grigg wrote:
Carl and Ben have rubbished non-repudiation
without defining what they mean, making it
rather difficult to respond.
I define it quite carefully in my paper, which I pointed to.
Now, presumably, they mean the first, in
that it is a rather hard problem to take the
cryptographic
Steve Schear wrote:
http://news.bbc.co.uk/2/hi/technology/3324883.stm
Adam Back is part of this team, I think.
Similar approach to Camram/hahscash. Memory-based approaches have been
discussed. Why hasn't Camram explored them?
They were only invented recently, and indeed, I've been planning
Amir Herzberg wrote:
Ian proposes below two draft-definitions for non-repudiation - legal and
technical. Lynn also sent us a bunch of definitions. Let's focus on the
technical/crypto one for now - after all this is a crypto forum (I agree
the legal one is also somewhat relevant to this forum).
Carl Ellison wrote:
If you want to use cryptography for e-commerce, then IMHO you need a
contract signed on paper, enforced by normal contract law, in which one
party lists the hash of his public key (or the whole public key) and says
that s/he accepts liability for any digitally signed
Carl Ellison wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm
Sent: Tuesday, December 23, 2003 1:44 AM
To: [EMAIL PROTECTED]
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
Ah. That's why they're trying to rename the
Amir Herzberg wrote:
At 04:20 25/12/2003, Carl Ellison wrote:
...
If you want to use cryptography for e-commerce, then IMHO you
need a
contract signed on paper, enforced by normal contract law, in which one
party lists the hash of his public key (or the whole public key) and says
that
Perry E. Metzger wrote:
In my opinion, the various hashcash-to-stop-spam style schemes are not
very useful, because spammers now routinely use automation to break
into vast numbers of home computers and use them to send their
spam. They're not paying for CPU time or other resources, so they
won't
Richard Clayton wrote:
and in these schemes, where does our esteemed moderator get _his_ stamps
from ? remember that not all bulk email is spam by any means... or do
we end up with whitelists all over the place and the focus of attacks
moves to the ingress to the mailing lists :(
He uses the
By popular demand, I've created a moderated alternative to the UKCrypto
mailing list. See
https://mailman.aldigital.co.uk/mailman/listinfo/ukcisnac for the
charter and subscription information.
This is intended to be complementary to the cryptography (because its
about the UK) and ukcrypto
Peter Gutmann wrote:
No they won't. All the ones I've seen are some variant on the build a big
wall around the Internet and only let the good guys in, which will never work
because the Internet doesn't contain any definable inside and outside, only
800 million Manchurian candidates waiting to
Adam Back wrote:
Here's a forward of parts of an email I sent to Richard with comments on
his and Ben's paper (sent me a pre-print off-list a couple of weeks ago):
One obvious comment is that the calculations do not take account of
the CAMRAM approach of charging for introductions only. You
Eric Rescorla wrote:
Cryptography readers who are also interested in systems security may be
interested in reading my paper from the Workshop on Economics
and Information Security '04:
Is finding security holes a good idea?
Eric Rescorla
RTFM, Inc.
A large amount of effort is
[EMAIL PROTECTED] wrote:
Ben Laurie wrote:
In OpenSSL we overwrite with random gunk for this reason.
What? No compiler is smart enough to say, The program
sets these variables but they are never referenced again.
I'll save time and not set them.
Sure it is, here's gcc -O3:
main()
{
int
Anton Stiglic wrote:
There is some detail in the FIPS 140 security policy of Microsoft's
cryptographic provider, for Windows XP and Windows 2000. See for example
http://csrc.nist.gov/cryptval/140-1/140sp/140sp238.pdf
where they say the RNG is based on FIPS 186 RNG using SHS. The seed is
based on
lrk wrote:
On Thu, Aug 12, 2004 at 03:27:07PM -0700, Jon Callas wrote:
On 10 Aug 2004, at 5:16 AM, John Kelsey wrote:
So, how many people on this list have actually looked at the PGP key
generation code in any depth? Open source makes it possible for
people to look for security holes, but it
Amir Herzberg wrote:
Perry E. Metzger wrote:
So the question now arises, is HMAC using any of the broken hash
functions vulnerable?
Considering that HMAC goal is `only` a MAC (shared key authentication),
the existence of any collision is not very relevant to its use. But
furthermore, what HMAC
Ed Gerck wrote:
Ben Laurie wrote:
Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?
Let's assume for a moment that a solution exists that satisfies your
requirements
John Gilmore wrote:
Crypto hardware that generates random numbers can't be tested in
production in many useful ways. My suggestion would be to XOR a
hardware-generated and a software-generated random number stream. If
one fails, whether by accident, malice, or design, the other will
still
Marshall Clow wrote:
At 10:44 PM -0700 10/20/04, Bill Stewart wrote:
At 05:23 PM 10/18/2004, R.A. Hettinga wrote:
http://news.bbc.co.uk/2/low/technology/3753886.stm
It's not clear that they work at all with inkjet printers,
and changing ink cartridges is even more common than
changing laser
Peter Fairbrother wrote:
Ben Laurie wrote:
OK, since my previous attempt to create a lower volume
ukcrypto-like-thing failed, I have concluded that the only way to handle
the problem is to produce a moderated version of ukcrypto. I know for
sure there's demand for this, but I also know
Ian Grigg wrote:
Alan Barrett wrote:
On Sat, 23 Oct 2004, Aaron Whitehouse wrote:
Oh, and make it small enough to fit in the pocket,
put a display *and* a keypad on it, and tell the
user not to lose it.
How much difference is there, practically, between this and using a
smartcard credit card in
Tyler Durden wrote:
Hum.
So my newbie-style question is, is there an eGold that can be verified,
but not accessed, until a 'release' code is sent?
proof-of-delivery protocols might help (but they're patented, as I
discovered when I reinvented them a few years back).
In other words, say I'm
Ondrej Mikle wrote:
On Tue, 14 Dec 2004 14:43:24 +, Ben Laurie [EMAIL PROTECTED] wrote:
But the only way I can see to exploit this would be to have code that
did different things based on the contents of some bitmap. My contention
is that if the code is open, then it will be obvious
Adam Back wrote:
I thought the usual attack posited when one can find a collision on a
source checksum is to make the desired change to source, then tinker
with something less obvious and more malleable like lsbits of a UI
image file until you find your collision on two input source packages.
Dan Kaminsky's recent posting seems to have caused some excitement, but
I really can't see why. In particular, the idea of having two different
executables with the same checksum has attracted attention.
But the only way I can see to exploit this would be to have code that
did different things
Bill Frantz wrote:
On 12/14/04, [EMAIL PROTECTED] (Ben Laurie) wrote:
Dan Kaminsky's recent posting seems to have caused some excitement,
but I really can't see why. In particular, the idea of having two
different executables with the same checksum has attracted
attention.
But the only way I can
and attest to the correctness of code C,
and then we can MITM and change surrepticiously with C'.
And with only 2^64 effort. Let me know when you're done.
Adam
On Wed, Dec 15, 2004 at 08:44:03AM +, Ben Laurie wrote:
Adam Back wrote:
Well the people doing the checking (a subset of the power users
John Kelsey wrote:
So, to exploit this successfully, you need code that cannot or will
not be inspected. My contention is that any such code is untrusted
anyway, so being able to change its behaviour on the basis of
embedded bitmap changes is a parlour trick. You may as well have it
ping a website
Jay Sulzberger wrote:
On Tue, 14 Dec 2004, Ben Laurie wrote:
Ondrej Mikle wrote:
[snipped many assertions without supporting evidence that MD5 cracks
improve attacks]
So, to exploit this successfully, you need code that cannot or will not
be inspected. My contention is that any such code
David Wagner wrote:
Ben Laurie writes:
Dan Kaminsky's recent posting seems to have caused some excitement, but
I really can't see why. In particular, the idea of having two different
executables with the same checksum has attracted attention.
But the only way I can see to exploit this would
C. Scott Ananian wrote:
On Wed, 22 Dec 2004, Ben Laurie wrote:
Blimey. Finally. An attack I can actually believe in. Excellent
Given recent discussion, this is perhaps a good moment to point at a
paper I wrote a while back on PRNGs for Dr. Dobbs, where, I'll bet, most
of you didn't read it.
http://www.apache-ssl.org/randomness.pdf
One day, I plan to implement the API I describe there.
Cheers,
Ben.
--
William Allen Simpson wrote:
Ben Laurie wrote:
William Allen Simpson wrote:
Why then restrict it to non-communications usages?
Because we are starting from the postulate that observation of the
output could (however remotely) give away information about the
underlying state of the entropy
David Farber wrote:
-- Forwarded Message
From: Rodney Joffe [EMAIL PROTECTED]
Date: Wed, 16 Feb 2005 07:36:36 -0700
To: Dave Farber [EMAIL PROTECTED]
Subject: SHA-1 cracked?
For IP
Hi Dave,
Bruce Schneier is reporting in his blog that SHA-1 appears to have been
broken by a Chinese group, and
Taral wrote:
On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote:
Want to protect your Mozilla/FireFox from such attacks? Install our
TrustBar: http://TrustBar.Mozdev.org
(this was the first time that I had a real reason to click the `I don't
trust this authority` button...)
Opinions?
Cute. I expect we'll see more of this kind of thing.
http://eprint.iacr.org/2005/067
Executive summary: calculate chaining values (called IV in the paper) of
first part of the CERT, find a colliding block for those chaining
values, generate an RSA key that has the collision as the first part of
Dan Kaminsky wrote:
The x.509 cert collision is a necessary consequence of the earlier
discussed prime/not-prime collision. Take the previous concept, make
both prime, and surround with the frame of an x.509 cert, and you get
the new paper.
Actually, not - an RSA public key is not prime.
Ian G wrote:
NSA names ECC as the exclusive technology for key agreement and digital
signature standards for the U.S. government
Certicom's ECC-based solutions enable government contractors to add
security
that meets NSA guidelines
I should note that OpenSSL also supports ECC.
--
It was suggested at the SAAG meeting at the Minneapolis IETF that a way
to deal with weakness in hash functions was to create a new hash
function from the old like so:
H'(x)=Random || H(Random || x)
However, this allows an attacker to play with Random (the advice I've
seen is that if one is
Dan Kaminsky wrote:
Ben,
x can equal either test vector released by Wang, and H(x) will be
identical. With H(x) identical, the rest of the HMAC stays identical too.
This does not appear to be correct - in my construction, i.e. without
padding, then the fact that x and x' differ means that
Nicolas Williams wrote:
On Mon, Mar 21, 2005 at 11:56:44AM +, Ben Laurie wrote:
It was suggested at the SAAG meeting at the Minneapolis IETF that a way
to deal with weakness in hash functions was to create a new hash
function from the old like so:
H'(x)=Random || H(Random || x)
Eric
Ken Raeburn wrote:
On Mar 22, 2005, at 11:51, Ben Laurie wrote:
This can be fixed quite easily:
H'(x)=H(H(x || H(x)) || H(x))
Doesn't this take us back to the original problem, by factoring in x
only at the start of hash computations, so H'(x') will generate the same
H(x') and the same internal
Nicolas Williams wrote:
On Tue, Mar 22, 2005 at 05:31:44PM +, Ben Laurie wrote:
Nicolas Williams wrote:
Now that we know that the attack is a differential cryptanalysis where
the attacker has to control the first pair of blocks of the original
message anything that makes it hard
Charlie Kaufman wrote:
All hash functions I'm aware of consist of an inner compression function
that hashes a fixed size block of data into a smaller fixed size block
and an outer composition function that applies the inner function
iteratively to the variable length data to be hashed. Essentially
Blumenthal, Uri wrote:
Ernie Brickell suggested the following construct:
H'(x) = H( H(x) || H(0 || x) )
Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)).
Sorry, I got my parentheses wrong. I meant...
H'(x)=H(H(x || H(0 || x)) || H(0 || x))
or:
H'(x)=H(H(x || H(0 || x)) ||
R.A. Hettinga wrote:
Police in Malaysia are hunting for members of a violent gang who chopped
off a car owner's finger to get round the vehicle's hi-tech security system.
Good to know that my amputationware meme was not just paranoia.
--
http://www.apache-ssl.org/ben.html
James A. Donald wrote:
From: Patrick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Lucrative-L] double spends, identity agnosticism, and
Lucrative Date: Tue, 29 Apr 2003 14:46:48 -0600 Importance: Normal
Sender: [EMAIL PROTECTED]
A quick experiment has confirmed the obvious: when a client
James A. Donald wrote:
--
PKI was designed to defeat man in the middle attacks
based on network sniffing, or DNS hijacking, which
turned out to be less of a threat than expected.
However, the session fixation bugs
http://www.acros.si/papers/session_fixation.pdf make
https and PKI worthless
https and PKI worthless against such man in the
middle attacks. Have these bugs been addressed?
On 20 May 2005 at 23:21, Ben Laurie wrote:
Do they exist? Certainly any session ID I've ever had
a hand in has two properties that strongly resist
session fixation:
a) If a session ID arrives
Ian G wrote:
On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote:
Ian G writes:
| In the end, the digital signature was just crypto
| candy...
On the one hand a digital signature should matter more
the bigger the transaction that it protects. On the
other hand, the bigger the
Anne Lynn Wheeler wrote:
Peter Gutmann wrote:
That cuts both ways though. Since so many systems *do* screw with
data (in
insignificant ways, e.g. stripping trailing blanks), anyone who does
massage
data in such a way that any trivial change will be detected is going
to be
inundated with
Perry E. Metzger wrote:
Have a look, for example, at
http://www.americanexpress.com/
which encourages users to type in their credentials, in the clear,
into a form that came from lord knows where and sends the information
lord knows where. Spoof the site, and who would notice?
Every company
Amir Herzberg wrote:
3. They did not actually spell out the problem in using SSL in the
homepage (like eTrade, for instance). But I think I know the reason
(they didn't confirm or deny). I think the reason is that they host
their site; in particlar, when I tried accessing it via https, I got
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key
Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going to them and not to someone who cleverly sent you an
altered version of
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real
problem
| is the key handling (how to make sure the DBA can't get the key,
cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are
[EMAIL PROTECTED] wrote:
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax
A brief altercation this evening with CERT over the recent hyperthread
caching issues has brought something that's been simmering at the back
of my brain to the forefront.
The recent hyperthread/cache key recovery trick, followed by DJB's
related (IMO) symmetric key recovery, and preceded by
Allan Liska wrote:
3. Use an on-screen keyboard.
For extra points, try Dasher.
http://www.inference.phy.cam.ac.uk/dasher/
--
ApacheCon Europe http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can
Victor Duchovni wrote:
On Thu, Jun 23, 2005 at 07:36:38AM -0400, Jerrold Leichter wrote:
- Develop algorithms that offer reasonable performance even if
implemented in unoptimized ways. This will be difficult
to maintain in the face of ever-increasing
Peter Gutmann wrote:
[EMAIL PROTECTED] writes:
Take a look at Boojum Mobile -- it is precisely the idea of using the cell
phone as an out-of-band chanel for an in-band transaction.
http://www.boojummobile.com
Banks here have been using it to authenticate higher-value electronic
Perry E. Metzger wrote:
Florian Weimer [EMAIL PROTECTED] writes:
* Perry E. Metzger:
Nick Owen [EMAIL PROTECTED] writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to
Peter Fairbrother wrote:
Florian Weimer wrote:
* David Alexander Molnar:
Actually, smart cards are here today. My local movie theatre in Berkeley,
California is participating in a trial for MasterCard PayPass. There is
a little antenna at the window; apparently you can just wave your card
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
That could be fixed. I think the right design for such a device has
it only respond to signed and encrypted requests from the issuing
bank directed at the specific device, and only make signed and
encrypted replies directed only
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Anonymity is a concern to me, too, but I suspect that it is hard to
get anonymity in a credit card transaction using current means, even
if the merchant isn't online. Pseudonymity, perhaps.
Can we not aim
Peter Gutmann wrote:
Perry E. Metzger [EMAIL PROTECTED] writes:
Why is it, then, that banks are not taking digital photographs of customers
when they open their accounts so that the manager's computer can pop up a
picture for him, which the bank has had in possession the entire time and
which
Ian Grigg wrote:
Too many words? OK, here's the short version
of why phising occurs:
Browsers implement SSL+PKI and SSL+PKI is
secure so we don't need to worry about it.
PKI+SSL *is* the root cause of the problem. It's
just not the certificate level but the business and
architecture level.
Florian Weimer wrote:
Can't you strip the certificates which have expired from the CRL? (I
know that with OpenPGP, you can't, but that's a different story.)
Yes, you can.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far
Hal Finney wrote:
I was just at Crypto yesterday and Hugo Krawczyk in his talk emphasized
the difficulty of securely designing key exchange protocols. He was
talking about implicit authorization protocols where the exponentiation
involves the long term public key(s). This protocol is different
Hal Finney wrote:
Ben Laurie writes:
Related to this is a project I keep considering and never quite getting
around to is to include a prime proof verifier in OpenSSL. It would be
pretty cool to have modes which only work when all relevant primes come
with proofs.
I've looked
Jerrold Leichter wrote:
| Apologies, slightly at cross-purposes here. For a start, Sophie Germain primes
| are needed for D-H (or rather, safe primes), and secondly, I was talking about
| proving arbitrary primes, rather than constructing provable primes.
Isn't *proving* primality rather
I wrote some code to show the internal state of MD5 during a collision...
http://www.shmoo.com/md5-collision.html
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the
[EMAIL PROTECTED] wrote:
So Miller-Rabin is good for testing random candidates, but it is easy to
maliciously construct an n that passes several rounds of Miller-Rabin.
Interesting! So how does one go about constructing such an n?
Maurer’s method doesn’t pick and test random candidates,
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ben Laurie writes:
I wrote some code to show the internal state of MD5 during a collision...
http://www.shmoo.com/md5-collision.html
Very nice, though you need to give a scale of rounds -- how many
horizontal lines per round?
1
Simon Josefsson wrote:
No, the certificate is verifiable in deterministic polynomial time.
The test is probabilistic, though, but as long as it works, I don't
see why that matters. However, I suspect the ANSI X9.80 or ISO 18032
paths are more promising. I was just tossing out URLs.
Surely
Simon Josefsson wrote:
Btw, could you describe the threat scenario where you believe this
test would be useful?
Well, that's an interesting question. I have to admit that I am no
longer sure there is any point. If people do an appropriate number of
rounds of Miller-Rabin whenever they're
Alexander Klimov wrote:
On Sun, 11 Sep 2005, Ben Laurie wrote:
Alexander Klimov wrote:
ECC is known since 1985 but seems to be absent in popular free
software packages, e.g., neither gnupg nor openssl has it (even if the
relevant patches were created). It looks like the main reason is some
Perry E. Metzger wrote:
What the world really needs is something between C++ and C -- a
language with very clean obvious semantics (like C) which does run
time bounds checking and strong typing, though it also needs explicit
escapes in the type system so you can write things like device drivers
Victor Duchovni wrote:
On Thu, Sep 15, 2005 at 08:51:02PM -0700, Bill Frantz wrote:
On 9/13/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote:
Generally speaking, I think software with a security impact should not
be written in C.
I agree. I also note that Paul A. Karger and Roger R.
Adam Shostack wrote:
On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote:
| On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote:
|
| My view is that C is fine, but it needs a real library and programmers
| who learn C need to learn to use the real library, with the bare
Sidney Markowitz wrote:
Excerpt from
Fact Sheet on NSA Suite B Cryptography
http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
NSA has determined that beyond the 1024-bit public key cryptography in
common use today, rather than increase key sizes beyond 1024-bits, a
switch to elliptic curve
Inspired by http://www.links.org/?p=12#comments, I have just produced
this prime:
1 - 100 of 296 matches
Mail list logo
