Cryptography-Digest Digest #200, Volume #11 Fri, 25 Feb 00 15:13:01 EST
Contents:
Re: - US "allows" encryption program online ("dude")
Re: RSA private key representation w/3 primes (Michael Sierchio)
Re: Crypto Speeds... (Terje Mathisen)
Re: protocols with limited transfer? (Mok-Kong Shen)
Re: - US "allows" encryption program online (Mok-Kong Shen)
Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the Internet
without any cause - just for your information. (Markku-Juhani O. Saarinen)
Re: I had me an Idea (Dynamic Key Encription) (wtshaw)
CRC-16 Reverse Algorithm ? ("Liu, Qingzhu [CAR:CF36:EXCH]")
Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the Internet
without any cause - just for your information. (Markku-Juhani O. Saarinen)
Postdoctoral Position (Sean Murphy)
Re: protocols with limited transfer? (David A Molnar)
Re: Passwords secure against dictionary attacks? (Johnny Bravo)
Re: How to Annoy the NSA ("Trevor Jackson, III")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Cryption Techniques and others (JPeschel)
Re: Processor speeds. ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: "dude" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: Fri, 25 Feb 2000 18:06:07 GMT
So then you are basically saying that when you post something on the
internet, you KNOW FOR A FACT exactly where that data will go? You know who
accesses what and when? IF that's the case, then we need to keep an eye on
YOU, not the government.
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
(SNIP)
> If this kind of 'negation' could be applied elsewhere, then nobody
> committing any crimes need ever be sentenced.
>
> M. K. Shen
> ----------------------
> http://home.t-online.de/home/mok-kong.shen
>
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RSA private key representation w/3 primes
Date: Fri, 25 Feb 2000 10:03:44 -0800
Paul Rubin wrote:
>
> In article <891sg7$lq9$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >Forgive the possibly stupid question, but I am looking
> >for a statement of the decryption operation and key
> >representation for RSA with 3 primes that is analogous
> >to the following 2-prime procedure as articulated in
> >PKCS#1:
>
> Basically phi(n) = (p-1)(q-1)(r-1) and everything else works out
> mostly the same way as before. You do secret key operations using the
> residues mod p,q,r and combine them with Garner's algorithm (see
> Knuth vol. 2 or any similar book).
>
> I have to ask, though, why do you want to mess around with a scheme
> like this, especially if you don't know enough basic math to be able
> to easily figure out all the details?
Actually, your rude retort doesn't seem responsive. I can guess that
the questioner understands how to use the extended Euclidean algorithm to
find d, the decryption exponent -- what she appears to be asking is
whether there is a standard octuple corresponding the the quintuple
form of the private key in which the primes are retained, and as articulated
in PKCS#1 version 2 or 3. There is more than one candidate form that works.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
Date: Fri, 25 Feb 2000 19:00:47 +0100
Jean Marc Dieu wrote:
>
> Is there any place on the Internet where we can find specific
> information about speeds with specific processors and specific
> operations? (Benchmarks, etc...). Fr example, what is the time required
> by Processor 'X' at speed 'Y' MHz to perform an hashing of a (say) 10Mb
> document using (say) RIPEMD160?
There's lots of info like this related to the new AES algorithms.
i.e. try http://home.cyber.ee/helger/aes/
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: protocols with limited transfer?
Date: Fri, 25 Feb 2000 19:28:13 +0100
David A Molnar wrote:
>
> In it, they mention a primitive called "pseudosignatures". These are
> signatures which can only "transferred" N times, in this sense :
[snip]
Question: If this mechanism is o.k., isn't it of essential value
in providing better e-mail protection as attempted by firms like
Disappearing Inc. and QVtech.?
M. K.
Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: Fri, 25 Feb 2000 19:38:25 +0100
dude wrote:
>
> So then you are basically saying that when you post something on the
> internet, you KNOW FOR A FACT exactly where that data will go? You know who
> accesses what and when? IF that's the case, then we need to keep an eye on
> YOU, not the government.
It is common knowledge that a web page is 'accessed', that is, the
data only 'goes' when somebody accesses it. I don't know where it
goes exactly. (One could install some software to check that perhaps,
but that measure can certainly be fouled.) But I definitely 'know'
that any bad guy can get the information if only he wants it and
thatat any time point from any geographical location. So I am
'knowlingly' exporting it (to the entire world) in the sense
of section 2 of the document.
M.. K. Shen
------------------------------
From: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
Subject: Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the
Internet without any cause - just for your information.
Date: 25 Feb 2000 18:44:45 GMT
(I know that this message does not have anything to do with cryptography,
but I think it is quite understable why I want to reply to this.)
In sci.crypt Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
> This person attacked me. His name is Markku-Juhani O. Saarinen
> <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland. He told me that I can
> not use my name, when I post on the USENET, and then started the
> information attack without any cause.
I have done no such thing. I have informed your ISPs about your e-mail /
USENET spamming and other network abuse. That's all.
I have worked as a system administrator on several occasions and I hate
hackers from the bottom of my heart. As tempting it would be to remove
your abusive usenet postings with cmsg cancels or to crash your system,
I regard that kind of activity as something that only assholes do. This is
one of the rules of sysadm ethics that I absolutely stick to.
> I can email all his emails to you and any other people around the world.
> I can identify his business relations and companies and I can provide
> all this information to you.
Why on earth would anyone be interested in my rather humble business
matters ? Besides they are public information.
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: I had me an Idea (Dynamic Key Encription)
Date: Fri, 25 Feb 2000 12:40:37 -0600
In article <k_ot4.2696$[EMAIL PROTECTED]>, "Tim"
<[EMAIL PROTECTED]> wrote:
> I had me an idea one day. Using an image to encrypt data. I call it Dynamic
> Key Encryption, i have shown it to a few people who may or may not know much
> about encryption. Most seem interested. I am curios what you think about it.
>
> Well this is what i got.
> 1 image
> a string of text
> and a set equation( for now).
>
> Each character in the text gets its own "small key". The key comes frome
> pixels of the image. The colors of the pixels are combined with the
> character value to produce and integer. after the Caricter recevs its Small
> Key the algorithm moves on to the next character and pixel.
>
I'm not sure that this is the best choice of name, nor are graphic colors
as constant or predictable as you think they are, something I have
investigated extensively on the Mac. But, I give you an E for effort.
--
Poor George. He thinks he can raise all the money he should ever
need to win, again. And, he does not seem to realize that he needs
all the votes he can get, from anybody, to win the presidency.
------------------------------
From: "Liu, Qingzhu [CAR:CF36:EXCH]" <[EMAIL PROTECTED]>
Subject: CRC-16 Reverse Algorithm ?
Date: Fri, 25 Feb 2000 14:18:56 -0500
Hello,
I try to implement an algorithm for crc-16 reverse
(Poly: 1 + x + x^14 + x^16) in PIC17c756 assembly code.
My questions are:
1. What does the "Reverse' mean ?
2. How is the dividing circuit looking like?
3. Is there a Byte-wise CRC calculation algorithm for it?
4. What is good text book about this topic?
Thansk for helps in advance.
--
Qinghu Liu
BWA, Nortel Networks
Phone: (613)763-3705
Fax: (613)763-6681
email: [EMAIL PROTECTED]
------------------------------
From: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
Subject: Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the
Internet without any cause - just for your information.
Date: 25 Feb 2000 19:29:26 GMT
Reply-To: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
(I know that this message does not have anything to do with cryptography,
but I think it is quite understable why I want to reply to this.)
In sci.crypt Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
> This person attacked me. His name is Markku-Juhani O. Saarinen
> <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland. He told me that I can
> not use my name, when I post on the USENET, and then started the
> information attack without any cause.
I have done no such thing. I have informed your ISPs about your e-mail /
USENET spamming and other network abuse. That's all.
I have worked as a system administrator on several occasions and I dislike
hackers from the bottom of my heart. As tempting it would be to remove
your abusive usenet postings with cmsg cancels or to crash your system,
I regard that kind of activity as something that only assholes do. This is
one of the rules of sysadm ethics that I absolutely stick to.
> I can email all his emails to you and any other people around the world.
> I can identify his business relations and companies and I can provide
> all this information to you.
Why on earth would anyone be interested in my rather humble business
matters ? Besides they are public information.
Stop harassing me.
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland
------------------------------
From: Sean Murphy <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Postdoctoral Position
Date: 25 Feb 2000 11:30:38 -0800
There is a postdoctoral position avaliable in Cryptology with the Information
Security Group, Royal Holloway, University of London. For further details see:
http://www1.rhbnc.ac.uk/sits-vac/cw16.html
Sean Murphy
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: protocols with limited transfer?
Date: 25 Feb 2000 19:18:37 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Question: If this mechanism is o.k., isn't it of essential value
> in providing better e-mail protection as attempted by firms like
> Disappearing Inc. and QVtech.?
Well, here's the thing - I get the impression from reading the paper
that the information is still there. It's just that the signature is no
longer verifiable.
It had been my impression that Disappearing, Inc is trying to prevent
the spread of the information itself. So while this technique may allow
someone to (try) disavowing the information after the fact, it may not
be strong enough for the legal needs envisioned by DI and other "e-mail
content control" companies.
Thanks,
-David
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Fri, 25 Feb 2000 14:23:45 +0000
On Fri, 25 Feb 2000 07:33:47 GMT, $[EMAIL PROTECTED] wrote:
>BTW, I'm in the process of implementing a password policy for my office of
>about ~30 people... what is a good password expiry... 30, 45, or 60 days?
It would depend on what threat level you are looking at, and the system
it is used on. If you have no external threat, like internet logons to
the system from outside the network and you just want to prevent one
employee from logging on as another, assigned two word pass phrases would
be about 26 bits, more than enough to prevent guessing games by employees,
especially if you have a system in place to record incorrect attempts
and/or a lockout if a given number of incorrect tries are made.
>I'm kinda partial to 45.. such a rotation would prevent month-based
>passwords ie: judyjan judyfeb judymar, etc etc.
Better off to assign passwords yourself. Go to www.diceware.com and
grab the list and some regular dice, generate as many words for each
person as needed, roughly 12.9 bits of entropy per word.
>Another method of passwd generation: Concatenating phrases. Take a common
>phrase such as "Dont hate me because Im beautiful", and take the first
>letter of each word, retain punctuation, then Skr1pt kiddy it.. you end up with:
>
>dhmb1'b.
>
>Easily remembered, nice size, and never gonna be dictionaried.
Roughly 35 bits of entropy easy enough to brute force, and if the users
forget to change I to 1, o to 0 ect they are going to be coming to you
constantly to get the password. :) You would be better off assigning
three distinct words from the Diceware list, 39 bits and pass phrases like
"magic rail doug" for example, are simple enough for users to remember.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
Date: Fri, 25 Feb 2000 15:03:08 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
"Donald S. Crankshaw" wrote:
> Jerry Coffin wrote:
> >
> > In article <879tg8$q95$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > says...
> >
> > [ ... ]
> >
> > > The safety of RSA appears to depend on the
> > > difficulty of factoring large numbers. This
> > > factoring is considered very likely to be a
> > > hard problem although it is not yet proven to
> > > be so. It is also not proven that the safety
> > > depends solely on the factoring. The main
> > > point of Peter Shor's famous algorithm is that
> > > it demonstrates that a quantum computer
> > > could factor large numbers efficiently (i.e.
> > > within polynomial time). For anyone who's
> > > interested, a good intro to codes and their
> > > vulnerability is Simon Singh's "The Code Book".
> >
> > You're still ignoring reality: we already KNOW exactly what effect a
> > quantum computer has on the amount of time it takes to factor a number
> > of a particular size. We already have the technology to continue use
> > RSA, and be protected from an attach using a quantum computer. People
> > using 2048-bit keys with RSA are already safe, even though the threat
> > is still purely theoretical.
> >
>
> I know this is an old thread, but I'm new to this group and I came
> specifically looking for views by Cryptologists on Quantum
> Computation. I work on a Quantum Computation project, so I may be able
> to contribute something to this discussion.
>
> For the record, I am not an Algorithms person. My work is more
> focused on the design of the qubit (the quantum system which stores
> the bit) itself and on the means of rotating it. Thus, I tend to be
> more focused on the physics and engineering than the algorithms, but I
> know enough about the Shor algorithm to say that 2048 bits is
> definitely not safe; at least not if the project I'm working on proves
> successful.
>
> It's important to say first that Quantum Computation is not like
> Parallelism, where you simply throw more power at the problem. What
> QC does is allow you to completely redefine how you approach the
> problem. In the case of the Shor algorithm, let's say you have b bit
> product of 2 primes. A quantum computer can solve the problem in
> O(b^2) quantum operations. A classical computer requires
> O(exp(cb^(1/3)). This is the number field sieve algorithm, the best
> known classical one. (It's much better than the slowest one, which is
> O(exp(b/2), and would take longer than the lifespan of the universe to
> factor a 2048 bit number.) I must admit that I know next to nothing
> about this algorithm aside from its order (mainly for comparison's
> sake), so I cannot say how quickly it could factor a 2048 bit number
> (mainly I don't know c). The quantum algorithm, however, would
> require on the order of 4 million quantum operations. The project I'm
> working on has an approximate quantum operation time of 10 ns, so
> we're talking on the order of .04 s to factor a 2048 bit number. Now
> I'm using the term "on the order of" a lot since there are all sorts
> of factors I'm leaving out, not to mention pre- and postprocessing.
> Like I said, I don't spend a lot of time working with the algoritms.
>
> Now, how feasible is this? Oh, the most optimistic estimate certainly
> wouldn't consider it possible in less than ten years. And that's
> being _very_ optimistic, assuming one of the solid state propositions
> works as well as we hope and that it scales quickly and easily. More
> realistically, maybe 25 years. There's also the very real possibility
> that it won't work at all--we'll be bogged down by the decoherence
> problem.
>
> Still, by the time quantum computation becomes feasible, 2048 bits
> will not be enough. And while you can increase the number of bits, it
> won't buy you as much as it once did.
>
> Oh, and as for the original subject line, "How to Annoy the NSA"...,
> who do you think funds all this quantum computation research anyway?
>
> Sincerely,
>
> Donald S. Crankshaw
> http://www.mit.edu/~dscrank
Thank you for the insights. Are you able to comment on the slope of the
quantum operation time? If we need to project the performance of QC into
the future we need an estimate of the rate of change in the fundamental
operating frequency in order to stay safely on the upper side of the
feasibility boundary.
The the slope is not apparent, perhaps you could explain the basis for the
10 ns per operation? I.e., what is taking that time? If, for example, it
is all speed-of-light delays than scaling the device down would affect the
operating frequency. But if there is some intrinsic "settling/sensing" time
per operation then scaling the device down could actually be counter
productive. What's going on during an "operation"?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 25 Feb 2000 19:58:04 GMT
On Fri, 25 Feb 2000 14:27:41 GMT, in <8963gp$n7j$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>> Cipher changing presumably would be a full-handshake event, and bugs
>> which result in a cipher mismatch would be immediately evident. Bugs
>> which involve the list of acceptable ciphers should be fairly
>> straightforward and we *can* test for those. What remains is the
>> random selection process, which already had to be visited in system
>> design anyway (for message keys). So I don't see a large opportunity
>> for error; this is a limited, well-controlled extension.
>
>It would be very usefull if you discuss in more detail your
>implementation ideas. I agree with Tim that it makes perfect sense, if
>you have a handfull of good ciphers why not use them.
This has been discussed. We have been having this particular thread
for months, and there have been earlier threads and discussions
probably for more than a year. I have a whole archived discussion
from last year on my site. I have proposed having and using many
ciphers for years.
The first step is to make ciphers interchangeable. I think each
"cipher" needs to have its own keying hash or equivalent which takes a
key phrase into the internal keying. (Sometimes we will actually use
a key phrase, but more often we will have stored or transient random
sequence keys.) Message keys will be created and transported as
usual, at a level above the ciphers per se.
Different ciphers have different block sizes. Indeed, we might well
want to include some stream ciphers in the mix (stream ciphers
probably must include nonlinear mixing with state for confusion / data
mixing rather than XOR). The higher system needs to choose the block
size (and also support re-keying after some number of blocks). We
also may need to have and choose RNG's.
I suggest that there be no global numeric coding representing a
cipher. Instead, each cipher should have a unique textual name. This
avoids the need to have some central organization allocate and
coordinate cipher numbers.
Each end should have a list of ciphers they will accept for receiving.
Typically one end will send (along with the current message, but
probably ciphered differently) the specification for the next desired
cipher stack. The other end then uses those ciphers, or if not, just
uses the old stack and sends back data and a response. The first end
thus has exactly two choices of cipher stacks after any change: the
specified stack and the old one. Error-detection indicates which is
in force at the far end. If the change did not take, the far end
probably sends back the list of ciphers it *will* accept. The option
to force a particular cipher at a particular level probably implies a
distinct list for each level. Meanwhile, the cipher may be being
changed in the other direction as well. Ciphers might well change on
a message-by-message or session-by-session basis. In practice, we
expect each end to have and keep the list of ciphers acceptable to the
other and to select from among them, thus requiring only the new
selections and not a new "acceptable" list each time. The actual
cipher selection would thus be made by index number within the list,
thus minimizing negotiation overhead. We may want to send those
numbers as text characters, however, instead of fixed-size fields.
>[..]
>I cant see any significant problems in randomley negotiating which
>ciphers to use.
Right. The worst error that cipher negotiation can have is to produce
the wrong cipher (or wrong block size, etc.) on the other end, which
would be rather apparent. This is a self-testing process: every time
we change ciphers and can recover the enciphered data, we know the
negotiation worked. That is far different than the usual
cryptographic protocol which we can only hope is correct.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Cryption Techniques and others
Date: 25 Feb 2000 20:02:46 GMT
"Osah" [EMAIL PROTECTED] writes:
>I tried to encrypt a file by XORing it with a string of integers (6bytes in
>length), i can decrypt it using the same integer string, but i want to know
>how to break it without using these integer strings (Any hint, algorithm
>description or code in C/C++ would help a lot).
>
Try using Vrack on your encrypted file. It's on the "Historical" page
of the site below.
>Also, where can i get more information on crypting algorithms or source
>code. I would like to learn more about it and how to implement them......
At the same site.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Fri, 25 Feb 2000 15:10:18 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Tim Tyler wrote:
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>
> [Re: why not use game consoles to build supercomputers!???]
>
> : I think part of the answer is the phase change that happened more than 25
> : years ago. I cannot find the attribution, but the thought is that
> : "We do not write software to tell the machine waht to do. We buy hardware
> : to execute the software." The translation is that software compatibility
> : increasingly outweighs raw hardware performance.
>
> For me the reverse is the case. Much of the software I develop and use is
> written in Java. Thus hardware performance increasingly outweighs
> software compatibility - since virtually anything with a JVM will do.
I suspect this is a hidden confirmation of the original thesis. The main
criteria isn't hardware performance, it is JVM support. Within the space of
supported platforms you are claiming that platforms can only be distinguished by
raw performance. But the systems that don't support your hardware environment
aren't even on your horizon.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
