Cryptography-Digest Digest #134, Volume #12 Thu, 29 Jun 00 07:13:01 EDT
Contents:
Station X: Decoding Nazi Secrets (John Savard)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Surrendering Keys, I think not. (Simon Johnson)
Re: Surrendering Keys, I think not. (Simon Johnson)
Re: Dynamical Cryptography algorithm (Sylvain Martinez)
Re: Hey Tom, you wanted to break it ! ;-) (Runu Knips)
Re: Dynamical Cryptography algorithm (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Key agreement in GSM phones (Arturo)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: SV: DES 64 bit OFB test vectors (Jack Spencer)
Re: Dynamical Cryptography algorithm (Simon Johnson)
Re: Yardley: Codebreaking or Torture (Casper H.S. Dik - Network Security Engineer)
Re: Yardley: Codebreaking or Torture (Casper H.S. Dik - Network Security Engineer)
Re: Remark on practical predictability of sequences (Tim Tyler)
SV: SV: DES 64 bit OFB test vectors ("Erik Olssen")
SV: DES 64 bit OFB test vectors ("Erik Olssen")
Re: Dynamical Cryptography algorithm (Sylvain Martinez)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Station X: Decoding Nazi Secrets
Date: Thu, 29 Jun 2000 07:16:18 GMT
I had the opportunity to read this book recently, and found it
enjoyable.
It contains much that is interesting, particularly about the human
side of Bletchley Park. For the first time, we are told what the
people there were told at war's end about the reason for the need for
continued secrecy.
Also, the cryptanalyst is named and details are given about the Noel
gift to British cryptanalysts...no, the message didn't arrive around
Christmas time, but the letter L did not appear in it, making it like
a Christmas present.
It contained one technical error, but an understandable one. It stated
that the diagonal board exploited the overall reciprocal character of
the Enigma, when in fact it exploited the fact that the plugboard
permutations were in themselves reciprocal.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Thu, 29 Jun 2000 10:06:51 +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
Although the details of the paper by Bellare et al. are too
involved for me to comprehend, it is evident that their
result does not affect the issue in the present thread. Let
me quote them:
We assume the cryptanalyst knows the parameters a, b, M
defining the LCG. (They are chosen at random but then
made public.) What is unknown to the cryptanalyst is the
seed k_0 used by the signer to start the LCG.
Since in our case the parameters a, b, M are naturally also
kept secret (one may for convenience of implementation even
use a fixed M, but a and b are certainly randomly chosen and
kept secret), their result cannot be directly or indirectly
transferred to the present context to apply for any useful
purpose.
M. K. Shen
------------------------------
Subject: Re: Surrendering Keys, I think not.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 01:22:47 -0700
Okay, i'll propose this again.
We have a document, m. We wish to encrypt this document, such
that no-one other than the legimitimate person can read it.
Now, to complicate matters, the government wants us to surrender
our keys if were involved in a criminal investigation. So how do
we satifiy the police, by providing a key (which is going to be
fake), and insure are information remains secure?
I figured since the output from any AES candidate should be no
different from random data, we could prepare a false one time
pad key, which decrypts to something totally correct (and/or
legal). The legitimate user of the encrypted file can still
decrypt it with an AES symetric algorithm, yet they have a back-
up OTP key incase the secret police come banging on the door,
demaning keys. They surrender the OTP key -> Or they try and
break the underlying block-cipher.
Do you see what i mean now?
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Surrendering Keys, I think not.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 01:27:52 -0700
Alan Braggins <[EMAIL PROTECTED]> wrote:
>Simon Johnson <[EMAIL PROTECTED]> writes:
>> Lets get this straight, before i start, the idea for the
system i
>> am proposing is to stop the police gaining circumstanial
evidence
>> against you.
>>
>> The prosecutors could say: 'He's using encryption and not
>> handing over the keys, therefore he's got something to hide.'
>
>No. Under the RIP, the prosecutors could say "We had reasonable
>grounds to believe he was using encryption, he hasn't handed
over the
>keys, and he can't prove (on the balance of probabilities) he
didn't
>have the keys, therefore he is committing a criminal offence."
Hey, he has submitted his keys..... just a phoney one which they
can't prove is incorrect as much as he can prove its correct.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: Dynamical Cryptography algorithm
Date: Thu, 29 Jun 2000 09:11:02 GMT
> Complicated math formulae are used in public key encryption - most
> symmetric ciphers use relatively simple operations.
I didn't know that...
> Having the algorithm vary depending on a user choice or platform is a
> bad idea. Since there are 4 variants of the algorithm, then an
>attacker
> could simply have 4 computers attempting to crack each one in
>parallel.
I do agree with this. but:
1) The security of the algo is not based on that. This is just an extra
feature so I think it's better to have it than not
2) There are 3 different bloks used in this algorithm, the user can
change the size of any of them:
(A) - The block of data in which in the algorithm will work in
- The size of the block used to seed (A)
- The size of the block used during the shuffle process in (A)
It's like having 4 different passwords.
> Consider a definition of what an encryption key is: "The only part of
> an algorithm that needs to be replaced to restore a compromised cipher
> engine to its full strength" Your key should just be a secret
> bitstring, known only to the encipherer and the decipherer. The
> algorithm should be *known,* not in any way secret [except for the
>key].
That's exactly what BUGS is.
Cheers,
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 29 Jun 2000 11:22:52 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Hey Tom, you wanted to break it ! ;-)
tomstd wrote:
> In the mean time I am working on my book and hopefully the first
> two chapters will be ready soon.
Whow, a book ? Cool. Damned, from where do you get all this
time...
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Dynamical Cryptography algorithm
Date: 29 Jun 2000 09:38:48 GMT
Sylvain Martinez <[EMAIL PROTECTED]> wrote:
> Sorry I am not familiar with blowfish and thought it was the case.
Then perhaps you ought to become more sure of your facts before claiming
such things? It's not exactly difficult.
> Is there any cryptography algorithm around allowing the user to change
> different value such as the size of the different blocks used in the
> crypt process ?
Yes. RC5, RC6, Rijndael, Hasty Pudding to name just four. Also
Anderson and Biham's BEAR and LION constructions work with arbitrary
block size.
> > Which particular ciphers are you thinking of here? Please ensure
> > that your answer clearly distinguishes your cipher from RC4, SEAL,
> > CAST128, Khufu, DES, and Hasty Pudding in this respect.
>
> What I try to say is that:
Ahh. You don't want to answer the question.
> I am not a math genius, creating a new algorithm using complex
> mathematical formalas would have been useless because I would then
> more or less copied an existing algorithm.
The purpose behind my question was to find out what you meant by
`complex mathematical formulas'. I don't see any in existing
cryptographic algorithms.
Public-key systems are based on (conceptually) rather simple operations
such as modular exponentiation. Even elliptic curve point addition
isn't very complicated.
Symmetric systems are constructed from the sorts of operations which are
commonly found on general-purpose computers, such as XOR, addition,
shifts and rotates, and table lookups.
So, I'll ask my question again: why is your system different from these?
There is mathematical theory which can analyse various operations, and
we can describe all of these ciphers in mathematical ways. Yours cannot
be an exception to this.
> If the different ciphers you talk about are not using complex maths
> then BUGS is like them.
Why don't you have a look at them, and get back to me, eh? Read
literature about how ciphers have been analysed, constructed, broken and
repaired. Then you'll really be in a position to design ciphers and
describe to us without looking like an idiot because you're talking
about things you don't understand.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 29 Jun 2000 09:41:47 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 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.
Ahh. But adding three more bits by keeping the chaining mode secret
will make all the difference. Of course. How silly of me to have
thought differently.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: Key agreement in GSM phones
Date: Thu, 29 Jun 2000 08:05:35 GMT
On Mon, 26 Jun 2000 13:18:24 +0200, Gerard Tel <[EMAIL PROTECTED]> wrote:
>
>Two questions on GSM protection, left after reading Biryukov/Shamir/
>Wagner's account on breaking the A5/1 stream cipher:
> 1. What protocol is used by the two parties to agree on the
> 64 bit keys used?
> 2. Is the encryption used ONLY on the ether link (between base and
> mobile) or is the data also encrypted during transportation over
> the fiber network?
>
>Gerard Tel
>http://www.cs.uu.nl/~gerard/
A technical paper describing the GSM algorithms in full will be much
appreciated.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 29 Jun 2000 10:04:22 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> But we were disputing on whether Scott Fluhrer's argument (to which
> I answered) involved TWO ciphers or ONE cipher!
We were? Oh. Perhaps you should have told me!
I thought we were agreed that his comment (preprocessing your bogus
cipher's input with something like Rijndael) involved two ciphers.
Unless you're now claiming that the original bogus cipher doesn't
actually count, of course.
> (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'??
Let's get a profile of this adversary, then.
* He's incapable, for some reason, of mounting any attacks against
ciphers which aren't brute-force. He also conveniently told you
this.
* His computers can break t-bit keys, but no longer. He can't buy any
more computers for some reason. You know what t is to within a
factor of eight, again because he told you. Oddly, the cipher which
you have no choice but to use is about 2^t to break.
* He can eavesdrop on every communications channel available to you.
That includes landline telephones, mobile telephones, the postal
service, motorcycle couriers, carrier pigeon, leased data lines to
the internet...
I think I might be forgiven for claiming that this was a rather strange
sort of adversary. The word `preposterous' springs to mind, actually.
> 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.
Duh. Why would the analyst waste his time doing this? Why doesn't he
attack the second block instead? He recovers the key and reads all but
the first block, which (most likely) wasn't very interesting anyway.
-- [mdw]
------------------------------
From: Jack Spencer <[EMAIL PROTECTED]>
Subject: Re: SV: DES 64 bit OFB test vectors
Date: Thu, 29 Jun 2000 20:04:25 +1000
> > 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 !
I think prices have gone down a bit : you can get one for less than $10Kfor
unlimited use.
Less for netlist only.
Then you have to add the price of the FPGA themselves.
> One core can do 1.000.000 dec/enc per sec.
The smallest core will do up to 7.5 million encryption/decryption per
second(480 Mbits/s).
A fully pipelined ECB DES core will do up to 120 million enc/dec per second
(7.68 Gbits/s).
This in FPGA, an ASIC will do better.
> )=;
>
> Regards Erik
JS
------------------------------
Subject: Re: Dynamical Cryptography algorithm
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 03:12:29 -0700
Could u publish this analysis aswell please?
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: Yardley: Codebreaking or Torture
Date: 29 Jun 2000 10:06:08 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
jungle <[EMAIL PROTECTED]> writes:
>John Savard wrote:
>> And the use of
>> drugs in this fashion would have seemed humane compared to direct,
>> conventional techniques of torture.
>"conventional techniques of torture" beautiful expression ...
Somehow the phrase "Congratulations Bob, Torturer of the Month"
springs to mind (Farside/Gary Larson)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: Yardley: Codebreaking or Torture
Date: 29 Jun 2000 10:07:47 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Ichinin <[EMAIL PROTECTED]> writes:
>Paul Rubin wrote:
>> Has history treated him too well?
>Same question about Alan Turing, one of the people that broke the
>enigma, and helped to preserv (most of) Europe a free speech zone,
>history didn't treat this guy well either.
I think Alan Turning can have few complaints about how history treated
him; how his fellow country men treated him is a different matter entirely.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Reply-To: [EMAIL PROTECTED]
Date: Thu, 29 Jun 2000 09:51:10 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> 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,
: since he can't recover the original sequence which he needs
: to do the inference in the first place.
This is essentially how (for example) Yarrow works.
It feeds a less than perfectly random sequence (in fact it uses a
counter) through a block cypher (3DES).
Typically hash functions - rather than block cyphers - are used in this
context - but the principle is similar.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: "Erik Olssen" <[EMAIL PROTECTED]>
Subject: SV: SV: DES 64 bit OFB test vectors
Date: Thu, 29 Jun 2000 12:41:43 +0200
> The smallest core will do up to 7.5 million encryption/decryption per
> second(480 Mbits/s).
> A fully pipelined ECB DES core will do up to 120 million enc/dec per
second
>
> (7.68 Gbits/s).
> This in FPGA, an ASIC will do better.
That seem's fast enough!
So do you have a retail source for this cores ?
Regards Erik
------------------------------
From: "Erik Olssen" <[EMAIL PROTECTED]>
Subject: SV: DES 64 bit OFB test vectors
Date: Thu, 29 Jun 2000 12:48:32 +0200
> 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.
Sorry "typo" it should be 10.000.000 dec/enc per sec.
Regards Erik
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: Dynamical Cryptography algorithm
Date: Thu, 29 Jun 2000 10:50:50 GMT
> > Sorry I am not familiar with blowfish and thought it was the case.
>
> Then perhaps you ought to become more sure of your facts before > >
> claiming
> such things? It's not exactly difficult.
I ought to do so in the futur indeed...
> > What I try to say is that:
>
> Ahh. You don't want to answer the question.
??
[...]
>
> Symmetric systems are constructed from the sorts of operations which
> are
> commonly found on general-purpose computers, such as XOR, addition,
> shifts and rotates, and table lookups.
>
> So, I'll ask my question again: why is your system different from
> these?
It uses the same ingredients but not the same receipes...
Ok then it is not different...
> There is mathematical theory which can analyse various operations, and
> we can describe all of these ciphers in mathematical ways. Yours
> cannot
> be an exception to this.
I agree !
I never meant to say so.
But the way This algorithm has been *designed* is not based on maths
> > If the different ciphers you talk about are not using complex maths
> > then BUGS is like them.
>
> Why don't you have a look at them, and get back to me, eh? Read
> literature about how ciphers have been analysed, constructed, broken
> and
> repaired. Then you'll really be in a position to design ciphers and
> describe to us without looking like an idiot because you're talking
> about things you don't understand.
Why are you so agressive ?
I could hit back but I am not interested into this, I am interested in
cryptography. I think I should open a new thread on the following
subject: "Why a lot of people on Usenet need to be really insulting, is
it because that make them feel better ?"
For god sake ! I just post a small article ! I don't pretend I am good
at anything, that I know cryptography, etc ...
I am an amateur willing to learn ! this is why I have done that and I
just try now to speak with experienced cryptographer !
Anyway. This is not the aim of my post, and I know how this will (badly)
evolve. Please email me if you've got a problem and we could speak about
that. Otherwise your comments are welcome.
Regards,
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
