Cryptography-Digest Digest #412, Volume #13 Tue, 2 Jan 01 14:13:00 EST
Contents:
Re: PKCS #15 ([EMAIL PROTECTED])
Re: Cryptanalysis Recomendations (Richard John Cavell)
Re: calculating 2048 bit public key ops with an 1024 bit engine? (Aki M Suihkonen)
Re: GOST 28147-89 ("[Basic]")
Audio-CD steganography? ("Michael Drüing")
Re: Genomes (Mathew Hendry)
Re: One Way Hash Functions ([EMAIL PROTECTED])
Re: A Censorship Resistant Digital Magazine Scheme (MagiconInc)
Re: Audio-CD steganography? ("Dave Rudolf")
Re: computing RSA keys ("Barron Hulver")
Wierd key (PGP v3 RSA) ("Thomas J. Boschloo")
New X9.68 Certificates ([EMAIL PROTECTED])
Re: Wierd key (PGP v3 RSA) (Lutz Donnerhacke)
unique codes (Eric Mosley)
Re: GOST 28147-89 (Tom St Denis)
Re: unique codes (Tom St Denis)
Re: computing RSA keys (Bill Unruh)
Re: computing RSA keys (Bryan Olson)
Re: AES in optimized x86 assembler? (Paul Rubin)
Re: AES in optimized x86 assembler? (Paul Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PKCS #15
Date: Tue, 02 Jan 2001 12:21:23 GMT
hi pradeep,
[..]
> The imported modules are
>
> UsefulDefinitions
> InformationFramework
> AuthenticationFramework
> CertificateExtensions
> ANSI-X9-62
> ANSI-X9-42
> PKIXCMP
>
> Does anybody know where I can find the ASN.1 definitions of these
> modules?
>
the first 3 modules i could locate from the snacc source .. as some
sample modules.. available from and modified by VDA (Van Dyke and
associates)
PKIXCMP protocol is described in rfc2459 (and so r the modules)
certificate extensions (pkcs????8?? ) not sure
second last and third last can't place now.
though i am not sure that this is the right forum. www.imc.org/smime
has the link to the S/MIME forum
regards,
rasane_s
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Richard John Cavell <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Recomendations
Date: Wed, 3 Jan 2001 00:03:58 +1100
On Tue, 2 Jan 2001 [EMAIL PROTECTED] wrote:
> it to anyone ( unless you want 200 pages of how
> to crack mono and poly-alphabetic cyphers).
And what's wrong with that?
==============
Richard Cavell
Medical Student, Debater, Chess Player, etc.
[EMAIL PROTECTED]
Newsgroups - Please keep any discussion on the group, and copy your
replies to me via email. (Server problems).
Do you want filthy language and abuse sent back to you? Just send me bulk
unsolicited email! Don't say you didn't ask for it!
------------------------------
From: [EMAIL PROTECTED] (Aki M Suihkonen)
Crossposted-To: sci.math
Subject: Re: calculating 2048 bit public key ops with an 1024 bit engine?
Date: 2 Jan 2001 13:53:22 GMT
In article <[EMAIL PROTECTED]> Paul Rubin <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Aki M Suihkonen) writes:
>> Perhaps I should have mentioned, that the ME is the *only* operation
>> available for a user in the *core* inside a smart card. Everything
>> else must be calculated with a reasonable latency with an
>> 8-bit 1MHz RISC processor.
>
>Are you sure that coprocessor doesn't also allow regular multiplication?
>Every one I've seen does that.
This one doesn't, at least in the documented (under NDA) instruction set.
Yes. It's peculiar.
--
Problems 1) do NOT write a virus or a worm program
"A.K.Dewdney, The New Turing Omnibus; Chapter 60: Computer viruses"
------------------------------
From: "[Basic]" <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Tue, 2 Jan 2001 15:06:22 +0100
then could you pls encrypt a block of plaintext with a key and sboxes of
your choice and post everything here so i can check it?
------------------------------
From: "Michael Drüing" <[EMAIL PROTECTED]>
Subject: Audio-CD steganography?
Date: Tue, 2 Jan 2001 15:31:11 +0100
Hi,
does anyone know if it is possible to store user-data (for example jpegs
etc.) in the subchannels of a normal Audio-CD? I know that there is about
4megs of empty subchannel-data on each CD. But is there any program that can
write such data (and, of course, read it back again)??
Thanks,
--Michael
------------------------------
From: Mathew Hendry <[EMAIL PROTECTED]>
Subject: Re: Genomes
Date: Tue, 02 Jan 2001 14:34:23 +0000
On Mon, 01 Jan 2001 12:29:00 +0100, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Does anyone happen to know the statistical properties of the
>genome sequences in general? Are they sufficiently 'random'?
They're not random or they almost certainly wouldn't work. :) But the recent
thread "compression of DNA sequences" in news:comp.compression might be of
interest. The thread starts at Message-ID
<[EMAIL PROTECTED]>
-- Mat.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: One Way Hash Functions
Date: Tue, 02 Jan 2001 14:32:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Nemo psj) wrote:
> MD5 and it was said to be a one way hash function, then I heard it
really
> wasn't. So no I'm all flusterd and since the Barns and Noble near me
dont like
> me very mush (long storie) could any of you point out where I can get
some info
> on One way Hash functions and or source or mathematicle epxlanations.
there is a collison in the compress function of MD5 as proven by Hans
Dobbertin in the paper entitled *"Cryptanalysis of MD5 Compress"(1996).
*http://www-cse.ucsd.edu/users/bsy/dobbertin.ps
link to one-way hash functions
http://www.tml.hut.fi/~helger/crypto/link/hash/
I hope it helps. I'll post the link of a PhD thesis about mathematics
of hash function(Yulian Zheng) tommorow.
W.S.Chong
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (MagiconInc)
Date: 02 Jan 2001 15:22:33 GMT
Subject: Re: A Censorship Resistant Digital Magazine Scheme
<<The problem of loosing one's key (or even having never
in possession of the key) has been raised in connection with
the law that the government of UK wanted to introduce, as far
as I can remember. Does anyone know the current status of
that law? >>
It passed, in July, I seem to remember; although not without an awful lot of
protest.
Paul Magnussen
Magicon Inc.
Making software simpler
------------------------------
From: "Dave Rudolf" <[EMAIL PROTECTED]>
Subject: Re: Audio-CD steganography?
Date: Tue, 02 Jan 2001 15:24:26 GMT
Any program that can read/write the CD as raw binary can do it. Also, in UNIX,
the system mounts each drive as a file system, but also has a device to read the
entire drive as one big binary stream. I believe it does the same for CD-Roms. I
don't know of any specific software that would do exactly what you want.
=======================================================
http://members.home.net/dave.t.rudolf
"Michael Drüing" <[EMAIL PROTECTED]> wrote in message
news:92soml$84jns$[EMAIL PROTECTED]...
Hi,
does anyone know if it is possible to store user-data (for example jpegs
etc.) in the subchannels of a normal Audio-CD? I know that there is about
4megs of empty subchannel-data on each CD. But is there any program that can
write such data (and, of course, read it back again)??
Thanks,
--Michael
------------------------------
From: "Barron Hulver" <[EMAIL PROTECTED]>
Subject: Re: computing RSA keys
Date: Tue, 2 Jan 2001 10:57:18 -0500
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:92r2sq$m7o$[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> > I'm making progress on the Javascript RSA implementation.
>
> If you have not already, be sure to look up PKCS #1 and find
> a known-good implementation you can test against.
>
> > I compute n-bit primes (using Miller-Rabin -- if anyone
> > can suggest a faster simple algorythm I'd be very
> > interested!)
>
> Miller-Rabin is good, but here's the sequence I recommend:
>
> 1. Sieve to eliminate candidates with small prime factors.
> 2. Do one base-2 Fermat test.
> 3. Do several Miller-Rabin tests.
>
> Exactly how many small primes to sieve against is
> unimportant; anywhere between 50 and 50,000 is fine. Step
> number 2 takes most of the time. In practice, every
> candidate that passes step 2 will pass step 3.
I'm not sure I agree with this 3-step recommendation. I agree that you should check
for
small prime factors, but why would a sieve be good for this? Why not a GCD
calculation?
Also, the Miller-Rabin test includes a Fermat test so I would eliminate step 2.
Finally, I believe it is the case that a Carmichael number (a type of composite number)
will pass steps 2 and 3.
If you want to use Miller-Rabin then I would do the following:
1. Eliminate small prime factors by multiplying them together and then
do a GCD with the proposed prime number.
2) Do a base-2 and base-3 Miller-Rabin test.
3) Do a Lucas test (not Lucas-Lehmer).
Barron Hulver
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.tech,alt.security.pgp,comp.security.pgp.discuss
Subject: Wierd key (PGP v3 RSA)
Date: Tue, 02 Jan 2001 16:47:02 +0100
Chris wrote:
>
> Chris Drake.
>
> PGP Key. RSA 2020/C0DED00D Fprint: 250A 7E38 9A1F 8A86 0811 C704 AF21
>
> 222C
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: None of your business
>
> mQESAgAAAAAAAAEH5Ar//This+is+Christopher+Drakes+PGP+public+key//
> Who/What+is+watcHIng+you//Di0nAraP+Ebz+iq83gCa06rGL4+hc9Gdsq667x
> 8FrpohTQzOlMF1Mj6aHeH2iy7+OcN7lL0tCJuvVGZ5lQxVAjhX8Lc98XjLm3vr1w
> ZBa9slDAvv98rJ8+8YGQQPJsQKq3L3rN9kabusMs0ZMuJQdOX3eBRdmurtGlQ6AQ
> AfjzUm8z5/2w0sYLc2g+aIlRkedDJWAFeJwAVENaY0LfkD3qpPFIhALN5MEWzdHt
> Apc0WrnjJDby5oPz1DXxg6jaHD/WD8De0A0ARRAAAAAAAAAAAbQvQ2hyaXN0b3Bo
> ZXIgRHJha2UgPENocmlzdG9waGVyLkRyYWtlQFBvQm94LmNvbT60SE5ldFNhZmUg
> c2VjdXJpdHkgc29mdHdhcmUgZGlyZWN0b3IgQ2hyaXN0b3BoZXIgRHJha2UgPE5l
> dFNhZmVAUG9Cb3guY29tPokBEgMFEDPXgvkcP9YPwN7QDQEB25oH4wWEhg9cBshB
> i6l17fJRqIJpXKAz4Zt0CfAfXphRGXC7wC9bCYzpHZSerOi1pd3TpHWyGX3HjGEP
> 6hyPfMldN/sm5MzOqgFc2pO5Ke5ukfgxI05NI0+OKrfc5NQnDOBHcm47EkK9TsnM
> c3Gz7HlWcHL6llRFwk75TWwSTVbfURbXKx4sC+nNExW7oJRKqpuN0JZxQxZaELdg
> 9wtdArqW/SY7jXQn//YJV/kftKvFrA24UYLxvGOXfZXpP7Gl2CGkDI6fzism75ya
> xSAgn9B7BqQ4BLY5Vn+viS++6Rdavykyd8j9sDAK+oPz/qRtYJrMvTqBErN4C5uA
> IV88P1U=
> =/BRt
> -----END PGP PUBLIC KEY BLOCK-----
Can someone explain this key to me? What's with the two plain text lines
at the start of the key block, how is that BASE-64 code?? How come my
version of PGP understands these headers?
And what about the 0xCODECODE keyID, doesn't that reduce security? Is it
possible to generate such a key using secure 1010 bit primes and doesn't
that take forever? (p == 1/(2^32), so instead of 1 minute it now takes
ten thousand years instead to create this not-so-random key).
And what about the wierd keylenght of 2020 bits? Wouldn't it be easy to
patch it to a 2048 bit key which would look more likely and leave the
signature on the key in tact?
This key looks insecure. In order to change the KeyID to 0xCODECODE, the
modulus has to be altered, most likely resulting multiple small factors
easing an attack on the private modulus.
Has Imad of ckt created a utility for this? Will signing and decrypting
still work (probably, judging from the signed files on his site).
Sorry for being so currious and asking such difficult questions,
Thomas
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED]
Subject: New X9.68 Certificates
Date: Tue, 02 Jan 2001 16:09:54 GMT
Can anyone give me a link to a reference work about
this certificate type?
It is e.g. used in the context of WTLS security for
wap. In the WTLS spec. I've found there the name but
no reference...
thx Rudolf
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To:
alt.security.pgp,comp.security.pgp.tech,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Wierd key (PGP v3 RSA)
Date: 2 Jan 2001 16:29:59 GMT
* Thomas J. Boschloo wrote:
>This key looks insecure. In order to change the KeyID to 0xCODECODE, the
>modulus has to be altered, most likely resulting multiple small factors
>easing an attack on the private modulus.
No. I changed the search mechanism only a bit in order to test only numbers
which are 'right' in the sense of a readable keyID. The following code
remains unchanged. To PGP it looks like two 'randomly' selected starting
points.
OTOH: How is this:
Key ring: 'work/crypt/data/pubring.pgp'
Type Bits/KeyID Date User ID
pub> 2048/19990101 1999/01/15 Root CA des Individual Network e.V. <[EMAIL PROTECTED]
Expire: 2000/12/31
Key fingerprint = 19 99 01 15 02 B4 7A 6B 33 D9 58 EE FC 09 8C E6
Generation was finished at 02:00 in the morning.
--
http://www.tm.oneiros.de/calendar/2001/index.html
------------------------------
From: [EMAIL PROTECTED] (Eric Mosley)
Subject: unique codes
Date: Tue, 02 Jan 2001 17:03:21 GMT
Hi,
I recentlt received a promotional gift certificate from Amazon. It was
designated by a unique code:
CLAIM CODE : XM82-VJY26W-H2LCNQ
Now, I need to generate unique codes like that! Does anybody know of an
appropriate algorithm or software library that could be used to generate
codes like that. I think the key thing here is that you have to be
unlikely to be able to guess somebody elses/another code..
Thanks,
Eric
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Tue, 02 Jan 2001 17:07:05 GMT
In article <92sn90$v3e$00$[EMAIL PROTECTED]>,
"[Basic]" <[EMAIL PROTECTED]> wrote:
> then could you pls encrypt a block of plaintext with a key and sboxes
of
> your choice and post everything here so i can check it?
On my website
http://www.geocities.com/tomstdenis/
I have a reference implementation of GOST with what I would call good
sboxes.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: unique codes
Date: Tue, 02 Jan 2001 17:28:47 GMT
In article <tRn46.931$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Eric Mosley) wrote:
> Hi,
>
> I recentlt received a promotional gift certificate from Amazon. It was
> designated by a unique code:
> CLAIM CODE : XM82-VJY26W-H2LCNQ
> Now, I need to generate unique codes like that! Does anybody know of
an
> appropriate algorithm or software library that could be used to
generate
> codes like that. I think the key thing here is that you have to be
> unlikely to be able to guess somebody elses/another code..
Simple do this
1. Take a secret piece of data
2. Take a serial number
3. Output the hash of the data and serial number, output the serial
number
Then attackers cannot make up other valid serial number/hashes pairs.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: computing RSA keys
Date: 2 Jan 2001 18:43:27 GMT
In <92qtng$ie1$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
]I'm making progress on the Javascript RSA implementation. See
]http://sourceforge.net/projects/shop-js for more information.
]I'm concerned about my key generation algorythm. I compute n-bit primes
](using Miller-Rabin -- if anyone can suggest a faster simple algorythm
]I'd be very interested!), then calculate (p-1)(q-1).
]Here's the trick I found.. I calculate a random n and find
] (p-1)(q-1) * n + 1
]this almost always factors easily.
]The trouble is that the result often has a public exponent which is
]relatively small (between 5 and 10^5). The private exponent is close to
]p*q (ie the public modulo).
Actually, one usually picks a public exponent like 5 17 33 --ie 2^n+1 to
make the calculation of the encrypted message easy for the sender
]Does this weaken the key? It seems to me that if the public key was
](for example) 7 someone might easily calculate a modulated 7th-root of
]the encrypted value even without knowing the private exponent. (Sorry I
]don't know the correct mathmatical language for this.)
This appears to be hard-- ie as hard as the factoring. But it is always
possible that there could be a breakthrough which make it easy.
NOte, make sure that your message to be sent is substantially larger
than (pq)^(1/7) ( assuming you use 7 as the public exponenet) or it is
trivial to take the seventh root. (The usual way is either to pad with
zeros to the right bring the length of the message up to the length of
pq, or to pad with 10000... to the left to again bring it up to the
length. Or pad with random digits and put in a byte telling the length
of the real message.
]Am I understand the situation?
]Is there a better way to calculate the multiplicative inverse? (I found
]one algorythm but it didn't look very simple & quick.)
Yes, but off hand I cannot reproduce it.
Any RSA implimentation has it.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: computing RSA keys
Date: Tue, 02 Jan 2001 18:42:34 GMT
Barron Hulver wrote:
>
> "Bryan Olson" wrote in message
> > Miller-Rabin is good, but here's the sequence I recommend:
> >
> > 1. Sieve to eliminate candidates with small prime factors.
> > 2. Do one base-2 Fermat test.
> > 3. Do several Miller-Rabin tests.
> >
> > Exactly how many small primes to sieve against is
> > unimportant; anywhere between 50 and 50,000 is fine. Step
> > number 2 takes most of the time. In practice, every
> > candidate that passes step 2 will pass step 3.
>
> I'm not sure I agree with this 3-step recommendation.
> I agree that you should check for small prime factors, but
> why would a sieve be good for this? Why not a GCD
> calculation?
A sieve is faster. For some large v (maybe 512 bits), we will
be checking the candidates: v, v+2, v+4 and so on. GCD (or
trial division) checks them independently. If we know v mod
83, then we should be able to tell whether 83 divides v+2
without long-integer math. On the other hand, the difference
is minor, since step 2 dominates the run time either way.
> Also, the Miller-Rabin test includes a Fermat test so
> I would eliminate step 2.
Base-2 Fermat is faster than Miller-Rabin, and step 2 is the
expensive part - the one where we spend that quartic time. I
consider Miller-Rabin to use a random base by definition.
> Finally, I believe it is the
> case that a Carmichael number (a type of composite number)
> will pass steps 2 and 3.
No. It would pass step 2, but Miller-Rabin catches Carmichael
numbers. In practice, we will never hit a Carmichael number.
> I would do the following:
> 1. Eliminate small prime factors by multiplying them
> together and then do a GCD with the proposed prime number.
> 2) Do a base-2 and base-3 Miller-Rabin test.
> 3) Do a Lucas test (not Lucas-Lehmer).
Reasonable. In step 1 we'd want to use just about enough of
the small primes so that their product is about the size of
the primes we plan to generate. Putting the base-2 and base-3
tests in the same step is misleading; the base-2 test
dominates the run time, while the base-3 is only called once
per generated prime. I don't think the base-3 test serves any
real purpose.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: AES in optimized x86 assembler?
Date: 02 Jan 2001 11:04:07 -0800
[EMAIL PROTECTED] (Thomas Pornin) writes:
> According to Paul Rubin <[EMAIL PROTECTED]>:
> > because there's no portable way to do multi-precision arithmetic in C
> > that uses the full capability of the PC architecture (specifically,
> > multiplication instructions that give double-width products).
>
> Actually there is one : unsigned long long. This type is at least 64-bit
> wide (and usually is that wide in PC common compilers) and is standard
> (since ISO 9899:1999, aka C99).
I didn't know long long was in c99, but anyway that's just a tiny fraction
of compilers, so it's not portable. To be portable, the code must compile
on the compilers that are in use in the real world, not just the very
latest versions.
> However, it appears that gcc is not very good at optimizing such code.
> Besides, the Intel instruction set is a real nightmare for compilers,
> so, indeed, you can get impressive speed-ups using hand-coded assembly
> -- on a particular chip. An extremely good code on a Pentium MMX will
> not perform that well on a Pentium II, for instance.
Yes. For that matter, the fastest way to implement RSA on the Pentium
IV appears to be with the SSE2 instructions, and I sure don't know of
any compiler that would know how to do that starting from a portable
implementation.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: AES in optimized x86 assembler?
Date: 02 Jan 2001 11:08:44 -0800
[EMAIL PROTECTED] (Paul Schlyter) writes:
> Now, if 99% of the CPU time will be spent on en/decryption, this
> would imply disk access will be some 100 times slower compared to a
> non-encrypted drive. Would anyone want to use this?
That would mean 99% of the time used by the encryption process. An
optimized Rijndael is supposed to need around 16 cycles/byte or
thereabouts. So if you're getting 5 MB/sec through the file system,
on a 500 mhz cpu that's 16% of the cpu, which I guess is tolerable.
> 1. How will you handle harddisks larger than 8 GBytes? The Int 13h
> interface will only be able to address 8 GBytes.
>
> 2. Since you're hooking into Int 13h, Win-9x will detect this and go
> back to 16-bit mode for each and every disk access. This alone will
> slow down disk access with perhaps a factor of 2. Will users accept
> this?
>
> 3. Your Int 13h patch will not work in Win-NT/2000.
Interesting points. FWIW, I'd consider a 2x slowdown in disk transfer
speed acceptable for something like this, but others might not.
------------------------------
** 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
******************************
