Cryptography-Digest Digest #423, Volume #13 Fri, 5 Jan 01 14:13:01 EST
Contents:
Re: Quadratic Residuosity Problem (Bryan Olson)
Re: Cryptlib and SQL Server databases (Peter Gutmann)
Re: Simple Sublimibimbimal Exercise (wtshaw)
Re: weten we die PIN? ("Marwijn Christiaans")
Re: Birthday Paradox ("Jakob Jonsson")
Re: Multi-precision arithmetic in C (was AES in optimized x86 assembler?) (Wei Dai)
Re: Simple Sublimibimbimal Exercise (Mok-Kong Shen)
Re: weten we die PIN? ("marcel555")
Re: Multi-precision arithmetic in C (was AES in optimized x86 assembler?) (Robert
Harley)
Re: Comparison of ECDLP vs. DLP (Bob Silverman)
Re: Crypt-X. (Doug Kuhlman)
Key scheduling (Doug Kuhlman)
Re: Any Ziplip Users Here???? (Wendel)
Re: Comparison of ECDLP vs. DLP (DJohn37050)
Re: Key scheduling (David Wagner)
Unsolved Elgar Cipher... ("Rob Marston")
Re: Simple Sublimibimbimal Exercise ([EMAIL PROTECTED])
Re: Simple Sublimibimbimal Exercise (wtshaw)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Quadratic Residuosity Problem
Date: Fri, 05 Jan 2001 06:26:33 GMT
Medvedev Michael wrote:
> I would like to find out, is it possible to decrease redundancy
> in Rabin public - key encryption?
[...]
> As a rule, if Allice wants to encrypt message M, she duplicates
> the message and encrypts X = MM. So Bob must finds out, which xi is
> duplicated.
Bob Silverman answered the question, but certainly it's
worth pointing out that many (probably most) Rabin
formatting schemes have fallen to chosen ciphertext (or in
the case of signatures chosen message) attacks.
If using Rabin encryption, definitely use something like
OAEP. For signatures, see "The exact security of digital
signatures: How to sign with RSA and Rabin" by Bellare and
Rogaway, available at several on-line sites such as
http://www-cse.ucsd.edu/users/mihir/papers/exactsigs.html
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Cryptlib and SQL Server databases
Date: Fri, 05 Jan 2001 06:47:04 -0000
"Michael" <m.condillac@/**DELETE**/blueyonder.co.uk> writes:
>Im currently working on my final year project that is focusing on Anonymity
>over the Internet using Digital mixes as described by Chaum. My theory is
>that a message is encoding using public keys of mixes in a reverse order and
>decoded at using the mix's private key and forwarded.
>My problem is that i am unsure as to how Cryptlib deals with private keys
>from a database. Can i create a number of key pairs using PGP and export
>into a SQL server database and use GetPublicKey and GetPrivateKey?
This probably isn't the right place to ask cryptlib questions, but I'll reply
here anyway... cryptlib stores X.509 certificates in relational databases, so
you can't store either PGP public or private keys there (although you can
convert the public key into a cert and store that). PGP keys are stored in
PGP keyrings... why do you want to use an SQL database to store PGP keys when
you've already got them in keyrings? You lose all the PGP key management
functionality if you move the data into an SQL database.
A much better option would be to use cryptlib's key management directly rather
than trying to import a whole pile of PGP keys, unless you really need to work
with PGP keys for some reason.
>Does Cryptlib expect the database to follow a certain structure?
Yes, but it's transparent to the user since it's all handled by cryptlib. All
you see is the put/get/delete key functions.
Peter.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple Sublimibimbimal Exercise
Date: Fri, 05 Jan 2001 00:55:06 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Olson) wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> | I am unable to discern the hidden content you claimed but I
> | am also not sure whether your scheme passes as steganography,
> | since it seems to be simply a sequence of symbols (the white
> | ones) in a particular alphabet which can also be an encryption
> | in the normal sense. Another quesiton: Could your scheme be
> | sensitive to the quality of the monitor that displays the
> | picture?
>
> The technique uses text that is just a slightly different color from the
> background (both close to black). If you remap the colors, you can see
> the text clearly:
>
Yes, the type is black and the mask is the next lighter shade of 256
grays. Leaving the donut holes in place is a tipoff.
Try filled donuts: www.radiofreetexas.com/wts/pix/card.gif
The original purpose of many of the pictures in that directory is to show
various ways that resolution can be diminished so as to allow for hidden
message of one form or another. I find the artistic results sometimes
pleasant or amusing. Some of the pictures lend themselves well to the
present method.
A similiar technique can be used in colored images.
Try to recover text: 217Skin.GIF
For comparison, 216Skin.GIF lacks the message.
Of course, there are many methods, and others may follow.
--
History repeats itself when given the opportunity.
Question repeating old mistakes.
Be certain of the outcome of repeating mistakes.
------------------------------
From: "Marwijn Christiaans" <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 5 Jan 2001 08:48:51 +0100
> >En dan?? De data wordt zwaar encrypt met sleutels op transport en
> >hardwareniveau. Voordat je de zaak encrypt hebt is/zijn de sleutels
alweer
> >gewijzigd. En zelfs al zou je de codering kunnen achterhalen hoe wil je
dan
> >je transacties uit die geldautomaat krijgen??
Als ze over de lijn gaan moeten ze wel gecodeerd zijn maar als een winkelier
een Nep automaat plaats heeft hij als je je pas er door heen haalt alle
gegevens om je magneet strip op een andere pas na te maken EN je pincode als
je hem intoets. Gelukkig zijn de meeste winkeliers wel ter goeder trouw.
Marwijn
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Birthday Paradox
Date: Fri, 5 Jan 2001 10:12:17 +0100
The probability P for no collisions among k elements from a set with n
elements is
(1-1/n)*(1-2/n)*...(1-(k-1)/n).
This means that -log P is equal to
- log(1-1/n) - log(1-2/n) - ... - log(1-(k-1)/n)),
which is approximately
\sum_{0 \le j < k} j/n = k(k-1)/2n.
k = sqrt(n) gives -log P ~ 1/2 (it is possible to show that the error term
is close to -1/3sqrt(n)). This implies that P ~ 0.6, so among sqrt(n)
elements we have a collision with probability ~0.4. Add two bits (i.e.,
replace sqrt(n) with 4sqrt(n)) and your collision probability is larger than
0.9996.
Jakob
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:9326km$eih$[EMAIL PROTECTED]...
> We know given a class of 'r' people and 'n' days the birthday paradox
> is given by
>
> p = 1 - P(n,r)/n^r
>
> Then why for a hash is it given by
>
> p = sqrt(n)?
>
> Tom
>
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: Multi-precision arithmetic in C (was AES in optimized x86 assembler?)
Date: Fri, 5 Jan 2001 01:21:32 -0800
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> unsigned long long still does not allow direct 32 x 32 -> 64 or
> 64 x 64 -> 128 bit multiplications, either of which will be more efficient
> than 64 x 64 -> 64.
Some compilers (including MSVC and GCC) are smart enough that the
following code will generate a 32 x 32 -> 64 multiply:
unsigned long x, y;
// replace unsigned long long with unsigned __int64 for MSVC
unsigned long long z = (unsigned long long)x*y;
--
http://cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Simple Sublimibimbimal Exercise
Date: Fri, 05 Jan 2001 10:33:43 +0100
Anonymous Remailer wrote:
>
> >Whereever there are black areas in a graphic, the same technique is good
>
> Easy, its the NSA charter.
>
> Steganography is a question of familiarity, thats why it is
> pointless to have "standard stego". Everyone has to invent
> a proprietary stego. This is a nice example, but the fact is
> that custom stego is limited to 0.00001 of Net users, the
> non-morons, all of which are already highly suspicuos and on
> many surveillance lists.
>
> Just use 256-bit crypto ... not Rijndael, of course :-)
The problem with stego with the aid of computer is that
it can just as well be detected with the aid of the
computer (in systematic ways), I believe.
Your remark is not correct. There are situations where
one needs to hide the presence of secret. And that need
may get bigger with the creation of new laws in certain
democratic countries.
M. K. Shen
------------------------------
From: "marcel555" <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 5 Jan 2001 12:16:49 +0100
Gaan we nu weer een jaar over die PIN zeiken. Dit begint deze nieuwsgroep
aardig te verpesten.
"Marwijn Christiaans" <[EMAIL PROTECTED]> schreef in bericht
news:933tj0$986$[EMAIL PROTECTED]...
> > >En dan?? De data wordt zwaar encrypt met sleutels op transport en
> > >hardwareniveau. Voordat je de zaak encrypt hebt is/zijn de sleutels
> alweer
> > >gewijzigd. En zelfs al zou je de codering kunnen achterhalen hoe wil je
> dan
> > >je transacties uit die geldautomaat krijgen??
>
> Als ze over de lijn gaan moeten ze wel gecodeerd zijn maar als een
winkelier
> een Nep automaat plaats heeft hij als je je pas er door heen haalt alle
> gegevens om je magneet strip op een andere pas na te maken EN je pincode
als
> je hem intoets. Gelukkig zijn de meeste winkeliers wel ter goeder trouw.
>
> Marwijn
>
>
>
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Multi-precision arithmetic in C (was AES in optimized x86 assembler?)
Date: 05 Jan 2001 12:41:38 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> "Paul Rubin" <[EMAIL PROTECTED]> wrote...
> > Are there any computers with 64*64->128 multiplication hardware?
>
> Actually the Alpha processor has it, however the registers are only 64-bits
> so they must be accessed using additional instructions. Someplace I actually
> have the assembly code to multiply 2 64-bit integers to get a 128-bit result
> in 3 instructions. It was part of a multiprecision library that may or may
> not have made it out the front door of DEC.
It is 2 instructions and is part of lots of programs since it is trivial:
==============================================================================
#ifndef __alpha
#error Get thyself an Alpha.
#endif
unsigned long p, q, lo, hi;
/* Low half. */
lo = p*q;
/* High half. */
#ifdef __GNUC__
asm("umulh %r1, %2, %0" : "=r" (hi) : "%rJ" (p), "rI" (q));
#elif defined(__DECC)
hi = asm("umulh %a0, %a1, %v0", p, q);
#else
#error You are out of luck, dude.
#endif
==============================================================================
Bye,
Rob.
.-. .-.
/ \ .-. .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' `-'
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Fri, 05 Jan 2001 14:34:28 GMT
In article <932sm7$qbq$[EMAIL PROTECTED]>,
"Martin Hamann" <[EMAIL PROTECTED]> wrote:
> I'm looking for at comparison of the stregths in a Elliptic Curve DLP
and a
> DLP in Zp*. I have seen a table stating which keysizes roughly offer
the
> same strength, for example 2^106 in ECDLP roughly equals 2^512
in "normal"
> DLP. I believe it is taken directly from a book or article, which I
cannot
> locate.
>
See "A Cost-Based Security Analysis of Symmetric and Asymmetric Key
Lengths" at
http://www.rsalabs.com/bulletins/
Anything you got from a book is certainly wrong, as I am sure
it did not use a good definition of "equivalent strength"
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Crypt-X.
Date: Fri, 05 Jan 2001 08:31:46 -0600
[EMAIL PROTECTED] wrote:
>
> There is an Australian software package called 'Crypt-X', for
> testing both stream ciphers and block ciphers.
>
> ( http://www.isrc.qut.edu.au/cryptx/ )
>
> Does anyone know more about this, and when testing a RNG, does
> this offer more than 'Diehard' ?
>
I've used it (for a block cipher), but I've not used 'Diehard' so I
can't really compare them. The interface is pretty easy to use. It
gives reasonably comprehensive results. The web pages give a reasonable
list of what tests it runs. The tests are pretty standard (in most
crypto books) but not having to code them myself saved me a lot of time.
If you have more specific questions, I can try to answer them for you.
Doug
> Thanks,
>
> Rudy.
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Key scheduling
Date: Fri, 05 Jan 2001 08:38:19 -0600
Certain ciphers (e.g. IDEA, DES) -- usually older ones -- have a very
simple key scheduling. Other, later ciphers (Twofish, AES) have much
more complicated key scheduling algorithms (often almost as complex as
the cipher itself).
Why? What attacks (if any) are there against the simpler key scheduling
algorithms? Is there a gain? If so, what?
Thanks!
Doug
------------------------------
From: Wendel <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.privacy
Subject: Re: Any Ziplip Users Here????
Date: Fri, 5 Jan 2001 14:56:29 -0000
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
> The story was about Hushmail, not Ziplip. Has the claim morphed to
> Ziplip (rather than Hush) being the company having trouble? The
> original story was quite specific about it being Hush.
>
It was mentioned somewhere along the line that Ziplip site was down. I
just thought I'd set the record straight. Sorry if I mislead.
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 05 Jan 2001 15:00:08 GMT
Subject: Re: Comparison of ECDLP vs. DLP
Check out my 2 papers on the Certicom white papers section at www.certicom.com.
"ECDSA" gives many advantages of EDSA. "ECC, Future Resiliency and High
Security Systems" gives a table of equivalent key sizes that was distributed by
NIST in ANSI X9.30 DSA-2 draft (using longer key lengths) and is coming to be
known at the NIST TIME Keysize Table.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Key scheduling
Date: 5 Jan 2001 15:34:37 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Doug Kuhlman wrote:
>Why? What attacks (if any) are there against the simpler key scheduling
>algorithms?
Weak keys and equivalent keys are obviously something worth avoiding.
More subtly, the hashing modes of operation (Davies-Meyer, etc.) for
block ciphers often stresses the key schedules very hard, and some
simple key schedules may not suffice for this application.
There are also related-key attacks to worry about, although I predict
that they are probably not a major concern in most practical uses.
For some discussion on attacks on too-simple key schedules, see
``Key-schedule cryptanalysis of IDEA, G-DES, GOST, SAFER, and triple-DES.''
John Kelsey, Bruce Schneier, and David Wagner. CRYPTO '96.
http://www.cs.berkeley.edu/~daw/papers/keysched-crypto96.ps
``Related-Key Cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X, NewDES,
RC2, and TEA.'' John Kelsey, Bruce Schneier, and David Wagner.
ICICS '97. http://www.cs.berkeley.edu/~daw/papers/keysched-icics97.ps
------------------------------
From: "Rob Marston" <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Unsolved Elgar Cipher...
Date: Fri, 5 Jan 2001 15:36:15 -0000
For those who are interesting in an old challenge's
we are trying to start an E-group to look into this
1897 puzzle...
http://www.egroups.com/group/Elgar-Cipher
All are welcome...
Rob
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple Sublimibimbimal Exercise
Date: Fri, 05 Jan 2001 16:07:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Steve K) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Wed, 03 Jan 2001 19:30:43 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >Pull up www.radiofreetexas.com/wts/pix/text.GIF.
> >
> >Save it and see if you can find the process to see the contents. I
> >left a few clues to egg you on, the confined spaces is some letters,
> >but they could be eliminated.
> >
> >Wherever there are black areas in a graphic, the same technique is
> >good for hiding content
>
> Well....
>
> I've see "TEMPEST resistant" fonts before, but that one certainly
> takes the prize.
sounds good and has the advantage that doesn't need any special
software.
hiding messages this way , should not be apparent by examining the base
64 encoding, as the pixels themselves are not altered.
have tried something similar in the past, where a message is hidden in
a graphic, by typing a textblock into the graphic, using the image
program text editor, and using an *invisible font*
{a true type font i wrote as freeware, that does not display 'any'
characters on the screen, originally intended for adding messages in
the whitespace of pdf documents. -[works, but displays as visible
message when the pdf document sections are copied to clipboard ]
using the 'invisible font' in image programs, is not detectable unless
one uses the image text editor for that image program.
has the advantage that the graphic does not require large monochromic
areas.
if anyone is interested, can e-mail the true type
'invisible font' [invisible1a.ttf], as well as a sample of disguised
text .
vedaal
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple Sublimibimbimal Exercise
Date: Fri, 05 Jan 2001 12:40:20 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> The problem with stego with the aid of computer is that
> it can just as well be detected with the aid of the
> computer (in systematic ways), I believe.
Stego can be much more varied than normal forms of crupto, even to hiding
otherwise encrypted stuff. There are no systematic ways to cover all
possible forms of crypto, just a small subset of them. Different forms of
hiding content and meaning can be added at the drop of a hat; dropping
hats would be hard to make a criminal offense. The wetdream of many
control freaks is that crypto in general is a containable process.
With the immediate example detection can be done in several ways. Three
are: manipulating the color table, working with brightness and contrast,
and repainting. The use of nicked letters, as in 217Skin.GIF, caters to
repainting.
> .....There are situations where
> one needs to hide the presence of secret. And that need
> may get bigger with the creation of new laws in certain
> democratic countries.
>
And, there is no humane way to sucessfully force all secrets to be told.
--
History repeats itself when given the opportunity.
Question repeating old mistakes.
Be certain of the outcome of repeating mistakes.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
