> On Thu, 01 Sep 2005 15:04:43 +0200, Simon Josefsson said:
>
>> If you control the random number generator, you control which
>> Miller-Rabin bases that are used too.
>
> Oh well, if you are able to do this you have far easier ways of
> compromising the security. Tricking the RNG to issue the sam
> One algorithm that results in a polynomially verifiable witness is:
>
> Almost All Primes Can be Quickly Certified
> http://theory.lcs.mit.edu/~cis/pubs/shafi/1986-stoc-gk.pdf
That's a very old algorithm. It was an intersting result at the time
(1986) because it is a primality proving algorith
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
>> [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?
>> Dont be concerned about secrecy of prime generated with Maurers
>> method,
>> the method generates primes that are almost uniformly distributed over
>> the
>> set of all numbers (this is different from another algorithm called
>> Shawe-Taylor, which is similar in functioning but only reaches
Some info on primality testing.
Miller-Rabin probabilistic primality tests work really well when you are
searching for a prime and picking candidates from a uniform random
distribution, also works well if you pick an initial candidate from a
uniform random distribution and then increment on that i
'chindogu' seems almost appropriate but maybe not exact
http://www.designboom.com/history/useless.html
http://www.pitt.edu/~ctnst3/chindogu.html
--Anton
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cry
> 2. Generalize the scheme (like the SPDC concept, or MPEG IPMP), more
> or less by making the standard part general, with non-standard "profiles".
This is kind of the ISO approach. For example, you standardize some
cryptographic protocol but give several choices of the protocol that
acheive the
>
>
> On Sat, 9 Jul 2005, [UNKNOWN] Jörn Schmidt wrote:
>
>> less attractive to commit credit card fraud. You are, however, not
>> making it harder. That's why I believe the credit cards companies will
>> indeed have a good, long look at smartcards. Probably not tomorrow or
>> next week but in the
> Perry E. Metzger wrote:
>
>> A system in which the credit card was replaced by a small, calculator
>> style token with a smartcard style connector could effectively
>> eliminate most of the in person and over the net fraud we experience,
>> and thus get rid of large costs in the system and get ri
>
> Dan Kaminsky <[EMAIL PROTECTED]> writes:
>> Credit card fraud has gone *down* since 1992, and is actually falling:
>>
>> 1992: $2.6B
>> 2003: $882M
>> 2004: $788M
>>
>> We're on the order of 4.7 cents on the $100.
Interesting statistics.
Seems like it's the same thing in Canada
http://www.
> [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
"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 or the like
> [EMAIL PROTECTED] writes:
>
>>I saw allot of requirements by security auditors that looked pretty
>> silly.
>
> "Must use 128-bit RSA encryption" has to be the all-time favourite.
>
> One I saw recently was a requirement for using X9.17 key management... in
> SSL.
>
> Peter.
One of my favourites
> [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
> On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote:
>> Yes, encrypting indexed columns for example is a problem. But if you
>> limit yourself to encrypting sensitive information (I'm talking about
>> stuff like SIN, bank account numbers, data that serves as an index to
>> external database
> | 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 management, but t
"Ken Buchanan wrote:"
> There are a number of small companies making products that can encrypt
> data in a storage infrastructure, including tape backups (full disclosure:
> I work for one of those companies). The solutions all involve appliances
> priced in the tens of thousands. The costs come
"Perry wrote:"
> In case you think the answer is regulation, by the way, let me note
> that most of the regulatory pressure I've seen on security policy
> results in people finding extremely well documented ways to do exactly
> what the regulators ask, to no actual effect. This is generally
> becau
Well, everyone who has Windows on their machine (at least a Windows 95
updated version and up, I think) has at least Microsoft's crypto provider,
and MS CAPI to use it! Most broswers implement HTTPS, so you have crypto
there as well.
I think we are already in a state where practically everybody
19 matches
Mail list logo
