Cryptography-Digest Digest #132, Volume #12 Wed, 28 Jun 00 20:13:00 EDT
Contents:
Re: DES 64 bit OFB test vectors (zapzing)
SV: DES 64 bit OFB test vectors ("Erik Olssen")
Re: Idea or 3DES (Tom McCune)
Re: Surrendering Keys, I think not. (zapzing)
Re: Surrendering Keys, I think not. (Simon Johnson)
cryptography and political dissidents? (David A Molnar)
Re: does 3des use only keys? (Shawn Willden)
Re: very large primes ("Paul Pires")
Re: Thoughts on "Cracking" of Genetic Code (Steve Roberts)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Java & Win32 (Andrew Leigh)
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: DES 64 bit OFB test vectors
Date: Wed, 28 Jun 2000 21:02:47 GMT
In article <[EMAIL PROTECTED]>,
Jack Spencer <[EMAIL PROTECTED]> wrote:
> > --
> > If you know about a retail source of
> > inexpensive DES chips, please let
> > me know, thanks.
>
> That's easy: get a DES core and cheap FPGAs.You'll be able to fit
> multiple cores on one chip, each
> running at over 120MHz (480 Mbits/sec)..
I'm sorry. I have no idea what a "core" or an "FPGA"
is. Furthermore I do not have much of a laboratory
or facilities, so if putting "cores" and "FPGA"s
together is terribly technical, I probably couldn't
do it. I have found one place that sells used chips
that has some DES chips, but they won't tell me the
price, they want me to write for a quote.
I might be willing to do that, but I would like some
idea of what to expect the price to be, before I get
the quote (history teaches it is best to be prepared
in these matters). I expect the price to follow a
roughly super proportional relation to speed, so if
you could just give me some examples of speed vs.
price, I would be very very grateful. Thanks.
> You can get free DES core from the web or a commercial
> one if you need support. Some commercial DES links:
>
> http://www.ocean-logic.com
> http://www.xentec-inc.com
> http://www.cast-inc.com
>
> I'm sure there's more.
>
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> JS
>
>
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Erik Olssen" <[EMAIL PROTECTED]>
Subject: SV: DES 64 bit OFB test vectors
Date: Wed, 28 Jun 2000 23:22:14 +0200
zapzing <[EMAIL PROTECTED]> skrev i
diskussionsgruppsmeddelandet:8jdp59$uaq$[EMAIL PROTECTED]
> In article <[EMAIL PROTECTED]>,
> I'm sorry. I have no idea what a "core" or an "FPGA"
> is. Furthermore I do not have much of a laboratory
> or facilities, so if putting "cores" and "FPGA"s
> together is terribly technical, I probably couldn't
> do it. I have found one place that sells used chips
> that has some DES chips, but they won't tell me the
> price, they want me to write for a quote.
>
> I might be willing to do that, but I would like some
> idea of what to expect the price to be, before I get
> the quote (history teaches it is best to be prepared
> in these matters). I expect the price to follow a
> roughly super proportional relation to speed, so if
> you could just give me some examples of speed vs.
> price, I would be very very grateful. Thanks.
>
VHDL/Verilog core modells
A des-modell source for instance from Cast is about 15000 dollars for a
single project !
One core can do 1.000.000 dec/enc per sec.
)=;
Regards Erik
------------------------------
Crossposted-To: comp.security.pgp.discuss
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Idea or 3DES
Date: Wed, 28 Jun 2000 21:28:28 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>> I find all this very interesting but to cut through all the knowledge
>> that is obviously commenting on this "and not to show my ignorance on
>> this subject"
>> but can i asume the i should'nt have my perfered algorithm "cast" and
>> change it to IDEA?? or 3DES???
>
>There's nothing known to be wrong with any of these three algorithms as
>used in PGP... at least not wrong enough to threaten your data. 3DES is
>the most conservative choice despite its shorter effective keylength, in
>my opinion, but I'm comfortable with the other two as well. So far.
Although I personally prefer IDEA, I agree that all three appear very
secure and any of them should serve very well.
>> I want my things to be as safe as posible. if i change my cast do i
>> need to make a new key????
>
>No. Your public key stays the same regardless of which symmetric
>algorithm you use.
If you generated your prior key with CAST set as preferred algorithm, and
you now want to have a key with a different preferred algorithm, you need
to change the preference setting and then generate a new key.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
Comment: My PGP Page & FAQ: http://www.McCune.cc/PGP.htm
iQCVAwUBOVpuRcMxrQ5/VTwtAQFpZwQAidVB65xMPDv4fxQ7ZUUwKZ5F1XUUdqzh
CQUKvVDtOPge0Y4hiASNdI/pQFvXCemySR9apOgHwO574IovHKV9RJhiN3gKYtHW
x5pE8FZ5J8zWELsCl571GvYCx+xBkiiX+uneb7cFBMdSi5UwbMztPF2etVYKxZFF
nVpRP7ps9hI=
=17cK
=====END PGP SIGNATURE=====
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Wed, 28 Jun 2000 21:22:47 GMT
In article <[EMAIL PROTECTED]>,
Andru Luvisi <[EMAIL PROTECTED]> wrote:
> zapzing <[EMAIL PROTECTED]> writes:
> [snip]
> > The police may want to see that the recipient also has a copy
> > of the OTP. The recipient, however, cannot have a message
> > he has not recieved yet. Dummy_Key, you will observe, depends
> > on the message sent. What happens if the police intercept the
> > message, preventing the intended recipient from recieving it,
> > and then demand of the recipient that he produce the OTP ?
> [snip]
>
> Somewhere in AC, Schneier describes this:
>
> Take a "fake" message and compress it.
> Tack the real message onto the space saved through compression.
> Encrypt it for real.
> Send it.
>
> The recipient can read the real message, and the compressed fake
> message. Uncompress the fake, xor it against the transmitted
> ciphertext, and voila, they have the same one time pad as you. There
> are, however, still issues of the modification date, position on the
> hard drive potentially indicating that the pad was newer than the
> encrypted file, and so on.
Um, no. I think you have misunderstood the scenario
I am talking about. The intended recipient never
recieves the message. It is intercepted by the People
Who Intercept Things (PWIT for short). The PWIT then
demand of you that you produce the encryption key.
If you say "it was an OTP" then they say "well the
recipient then has the OTP too, right, so let's go
see". But the recipient has not recieved your most
recent message, so he can't "voila" anything in the
way you have described. His OTP will be shorter than
yours, and it will look like something is up. :(
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Surrendering Keys, I think not.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Wed, 28 Jun 2000 14:39:47 -0700
Good point,
However, for personal encryption, it is perfect.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: cryptography and political dissidents?
Date: 28 Jun 2000 21:36:58 GMT
Hi,
Has anyone published anything on the use of cryptography by political
dissidents or other organizations such as Amnesty International?
What are the usability requirements for cryptographic software?
What sorts of traces will get someone in trouble? What kind of
bandwidth, memory, and access to compiler limitations are out there?
There are several systems I know of which are created with dissidents
at least partly in mind (I'm working on one, hence the question
http://www.freehaven.net). I have found less on whether such systems
are used in the field, and if so, how. Right now I remember a talk by
Schneier a few DEF CONs ago in which he pointed out the dangers of
current steganography software and not much else.
Anyone know where to look for such information?
Thanks,
-David Molnar
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: does 3des use only keys?
Date: Wed, 28 Jun 2000 16:05:07 -0600
"David A. Wagner" wrote:
> But exhaustive keysearch is not the best attack on 2-key 3-des, so
> the keylength is the wrong measure.
Where can I find information about better than exhaustive search attacks on 3DES?
Thanks,
Shawn.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: very large primes
Date: Wed, 28 Jun 2000 15:12:48 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Yah. Point taken.......
>
> But then i'm not a real mathematician, nor a researcher.....
> Indeed if i was, then i would not have to consult this forum.
>
> And prehaps critically, i don't have the time for it.
Shucks, that's not a requiremet for a mathematician or a programmer. If
pencil and paper intimidate, try a spreadsheet. Excell or Quattro will do
the job nicely. You must trust your answers based upon what you know, not by
what an expert says.
You would have been chasing your tail if these guys developed a sense of
humor and andswered your querry with, "Oh my god, it works!"
Paul
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: Thoughts on "Cracking" of Genetic Code
Date: Wed, 28 Jun 2000 22:21:37 GMT
[EMAIL PROTECTED] (John Savard) wrote:
>On 27 Jun 2000 13:31:34 EDT, [EMAIL PROTECTED] (Information System)
>wrote, in part:
>
>>As I understand it, what has been accomplished is
>>the compilation, in crypto terms, of a complete and possibly
>>accurate transcription of the ciphertext.
>
>Well, many years ago, the genetic code was "cracked" in the sense that
>a code by which three bases (from a set of four) along an RNA or DNA
>molecule represented an amino acid was determined.
>
>The Human Genome Project is indeed not really analogous to
>codebreaking, and indeed the relationship between the various variant
>forms of proteins formed by different alleles (the different forms of
>the same gene) and observed traits in humans has not been completely
>established - and will not be for quite some time.
>
The genetic code is a "code" in the sense that it is information
enCODEd in a particular way, like "ASCII code" for example. But the
concept of "code" in the public's mind leads to the idea of "breaking
the code" which leads to more information.
What I predict will occur is that nutters will now start to find
messages in the genome sequence. It happened to Shakespeare and the
Bible, why not this?
Steve Roberts
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Thu, 29 Jun 2000 02:05:31 +0200
[EMAIL PROTECTED] wrote:
> Well, hardware generators are like one time pads, unbreakable. If you take a
> strong block cipher and feed it back than you have a random sequence such
> that no known way to predict it exists - but no proof that that it cannot be
> done either.
>
> I guess the point is that you cannot prove that a pseudo-random generator is
> unpredictable.
My (heuristic) argument is this: A sequence from PRNG is not perfect,
so it has in some sense patterns that could be exploited. Now a natural
language text also has patterns. If we consider that a given cipher is
(practically) secure for encryption of natural language texts, then there
is no reason in my view to consider it to be insecure for encryption of
PRNG output. In other words, the analyst can't recover the PRNG
output. Certainly the scheme doesn't have provable security. However,
neither does any given block cipher provide provable security, but only
practical security. As you mentioned, even hardware random
sequences doesn't have provable security (in the absolute sense).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 29 Jun 2000 02:05:51 +0200
Mark Wooding wrote:
> Then you should *get* a good cipher, rather than pratting about with a
> bad cipher and sellotaping[1] extra bits of security to it. It's just
> not going to work.
Fine. Do you think that one can always get such a 'good' cipher in ALL
cases? Note that there is no absolutely objective evaluation of the
strength of a cipher, nor that of risk. Hence a user might always
desire further improvements of his security. 3DES is mostly considered
to be secure at the current moment. But there is no strong argument
to convince someone who fears that it is not secure enough for his
application.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Thu, 29 Jun 2000 02:05:37 +0200
"John A. Malley" wrote:
> Mok-Kong Shen wrote:
> >
> > Pseudo-random sequences, being deterministically generated,
> > always involve the issue of predictability. On the other
> > hand, a good cipher prevents the opponent to obtain the
> > plaintext from the ciphertext. It seems logical to conclude
> > that, if one feeds a pseudo-random sequence to a good cipher,
> > the resulting output sequence is practically unpredictable,
>
> This rang a bell.
>
> There's a paper by M. Bellare, S.Goldwasser and D. Micciancio
> demonstrating this assumption does not always hold. They show that if a
> Linear Congruential Generator (LCG) or truncated LCG produces the random
> choices (nonces) required for the Digital Signature Standard, then the
> results are completely breakable when the attacker knows the
> coefficients of the LCG but not its seed value. The masking of the
> nonces by the DSS algorithm can be solved even though it seems nonce
> recovery should require solving the discrete logarithm problem.
>
> Paper's at http://www-cse.ucsd.edu/users/mihir/papers/dss-lcg.html
>
I'll look at the paper to see if it addresses directly the matter of my
scheme (I hope I'll be able to understand the material). In the meanwhile
it would be nice if you would like to also read and comment on my
response to a follow-up of [EMAIL PROTECTED] in this thread.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 29 Jun 2000 02:05:43 +0200
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > You snipped out what Scott Fluhrer worte and then provided the wrong
> > argument. Here is what he wrote before my sentences quoted above:
>
> No, not really. Whether you use a good cipher *followed* by a bad
> cipher or just the good cipher on its own doesn't really matter (by
> definition of `good'), as long as you use it.
But we were disputing on whether Scott Fluhrer's argument (to which
I answered) involved TWO ciphers or ONE cipher!
> > Sorry, I don't yet understand. Let me quote what you wrote in full:
>
> Maybe I'm confusing people by considering the real world for once. I
> know it's surprising, because I don't often do this, but I think that in
> this instance it's the right thing to do.
>
> If we're in a real-world situation where we know enough about our
> adversary (or adversaries -- let's assume they're all working together,
> so there's just one big adversary to consider) that we can predict both
> his approach to cryptanalysis and his computational capabilities, I
> firmly believe that whatever intelligence provided us with this
> information would also provide us with enough information to determine
> some other way of communicating which was immune from attacks by this
> adversary anyway.
(I said many times) if you have to communicate through public providers
and there is no other possibility, how are you going to obtain 'some other
way of communicating which was immune from attacks by this adversary
anyway'??
> To summarize my position as it now is:
>
> * Block cipher modes are not, nor should be, designed to increase the
> security of the cipher. If the cipher, by itself, is not strong
> enough, use a different one. If real-world constraints prevent
> this, then fight the constraints, because they're wrong.
>
> * Using the choice of mode as a secret provides a uselessly small
> increment of security. It's almost transparent to known- and
> chosen-plaintext attacks.
>
> * An ability to compute the opponent's resources with regard to
> cryptanalysis is unlikely to be isolated: you should be able to
> determine others of his capabilities too, and thus work out a way of
> communicating securely without the need for cryptography of any
> kind.
>
> * I'm not interested in pursuing this argument further. I don't think
> I can express myself much more clearly, and I can't be bothered
> wading through the same old twaddle from you. If you have something
> genuinely new to add to the discussion, I might pick up on it.
I think that I'll simply counter your second paragraph above. Let's first
consider the familiar CBC. Suppose one uses a secret IV (of the size
of the block). If the analyst brute force the first block, how much
additional work does he have when compared to the case where
there is no xoring with the IV? A few bits? Please give a plausible
argument, if you think so. Now for the second and following block,
the analyst does know the chaining value. That's why I don't
prefer CBC. As I said previously, there are other chaning modes
than CBC where all the chaining values are unknown to the analyst.
(I thought that one of the modes I mentioned in the original post
was good. Shawn Willden clearly proved that I was wrong. See my
response to him for a non-linear chaining mode that should function.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 29 Jun 2000 02:05:57 +0200
Shawn Willden wrote:
> Shawn Willden wrote:
>
> > I haven't thought about the variant using addition mod 2^32. Frankly I don't
> > remember the properties of addition in Zn well enough (shame on me).
>
> OTOH, yes I do. Unless memory, intuition and a few hastily worked examples fail me,
> this would just be:
>
> Let Cj = E(sum(P,j) + sum(C,j-1))
>
> To attack using brute force, first pick two adjacent ciphertext blocks, Cj-1 and
> Cj. Pick a key and decrypt both blocks, yielding D(Cj-1) and D(Cj). Then
> calculate the additive inverses of D(Cj-1) and Cj-1 and calculate:
>
> D(Cj) + -D(Cj-1) + -Cj-1
> = (sum(P,j) + sum(C,j-1)) + -(sum(P,j-1) + sum(C,j-2)) + -Cj-1
> = sum(P,j) + -sum(P,j-1) + sum(C,j-1) + -sum(C,j-2)-Cj-1
> = Pj + Cj-1 + -Cj-1
> = Pj
You are right. Many thanks for the demonstration. This indeed clearly
shows that my view up till now that there could be chaining modes
among what I mentioned in the original article that offer more than
a few bits is wrong. Your demonstration simultaneously provides me
the insight that one should use non-linear values for chaining, if one
desires to do better. An idea that suggests itself is to use the square
of the sum as chaining value, for that evidently escapes your attack.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Andrew Leigh)
Subject: Java & Win32
Date: Thu, 29 Jun 2000 00:10:42 GMT
I was wondering if anyone could help me out here. I'm new to
cryptography so I don't know if there is an obvious solution to this
or not.
I basically need to digitally sign a certificate in Java, and in
Delphi (Win32). The signatures must match under both systems. I also
need to verify the certificates under both systems. So, a signature
created under Java must be able to be verified under Win32. And vise
versa.
I've searched the web and can't find any cryptography tools that do
this. All the tools are either for Java or Win32. There are mechanisms
(like DSA & RSA) available for Java and C, but they are implemented
differently and therefore aren't compatible.
Are there any another signing mechanisms for both Java and Win32
available? Something implemented in C would be fine because I could
build a DLL or inbed it into Delphi.
Any help would be appreciated.
Andrew Leigh
[EMAIL PROTECTED]
------------------------------
** 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
******************************
