Cryptography-Digest Digest #386, Volume #12 Wed, 9 Aug 00 08:13:01 EDT
Contents:
Re: chap authentication scheme? (Mark Wooding)
Re: 3DES test vectors (Mark Wooding)
Re: counter as IV? (David A. Wagner)
Re: counter as IV? (David A. Wagner)
Crypto and CCTV ("Dave Foulger")
Re: New Patent to an old machine ("Darth Maul")
Re: Physical RNG ("CMan")
The Feistel network in Twofish ("kihdip")
Authentication ("Rick Braddam")
Re: asymmetric encryption for my keycode generator (ArchimeDES)
Re: Multiple encryption passes (ArchimeDES)
Re: Using 256bits key for IDEA? (Michael Portz)
Software license software with PK ???? ("Benny Nissen")
Re: asymmetric encryption for my keycode generator ("Benny Nissen")
Re: counter as IV? (Bodo Moeller)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: chap authentication scheme?
Date: 9 Aug 2000 09:37:02 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> Bill Unruh <[EMAIL PROTECTED]> wrote:
> > The authenticator has a modulus N (prime?) and a generator g. The stuff
> > stored in the database is
> > username, salt s, g, N, g^ps modN
> > The challenge to theuser is
> > s,N, g^x modN where x is a random number
> > Response is
> > (g^x modN)^ps modN
> > which the authenticator can compare with (g^sp modN)^x modN
>
> There is a problem with active attacks. Any malicious party can
> pretend to be the server, pick a random x, challenge the user, and
> from the user's response learn the user's password. The user has no
> way to know that this has happened, since the server is not
> authenticated in any way.
Can you explain this attack in more detail, please? I can't see how it
works.
I've been assuming that everyone trustworthy is following standard `good
practice': the modulus n is fixed for all users, and chosen so that
discrete logs are hard. Similarly, g is chosen to generate a large
prime-order subgroup, and the challenge g^x is checked for membership of
the subgroup.
Given this `good practice', I can't see an attack. Our malicious party
picks some other element of the subgroup g' = g^x for some x (which
might not be known to the adversary). However, g' still has large order
-- the prover will refuse to cooperate if g' isn't in the subgroup. He
picks some value s and sends his challenge. In return, he gets v =
g'^{ps}. He can compute g'^s. If he knew x, he could have computed v =
(g^p)^{sx} himself and would therefore have learned nothing new, so
we'll assume that he doesn't.
Extracting p from this mess isn't quite the discrete log problem, though
it's an adaptive variant, where instead of a pair (g, g^p) we're given
an oracle which will return g'^p for arbitrary g' within the subgroup.
Let's see if I can prove this. Suppose we have an adversary A which can
extract p using t modexps and k queries to an oracle O which, given s
and g', will return g'^{ps} iff g' is a member of the subgoup generated
by g.
My adversary A' simply wants to compute p using an oracle O' which,
given g' in the subgroup generated by g, returns g'^p. It simulates
O(s, g') = O'(g')^s and then runs A; p drops out the far end, after t +
k modexps and k oracle queries.
Is my intuition about the difficulty of adaptive discrete log wrong?
Even when `good practice' is observed?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: 3DES test vectors
Date: 9 Aug 2000 09:40:11 GMT
Irene Gassko <[EMAIL PROTECTED]> wrote:
> Do there exist tables with 3DES test vectors with 2 or 3 different keys?
> If someone has those, could you please send them to me or point to a
> URL?
Format: key plaintext ciphertext, all big-endian.
0123456789abcdeffedcba9876543210
0123456789abcde7 7f1d0a77826b8aff;
0123456789abcdeffedcba987654321089abcdef01234567
0123456789abcde7 de0b7c06ae5e0ed5;
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: counter as IV?
Date: 8 Aug 2000 21:15:54 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Hmm, what about a modified CBC encryption, where instead of XORing the
> first block of plaintext with the IV before encrypting, we encrypt the
> IV, *then* XOR it with the first plaintext block. Then, a counter as IV
> would probably be perfectly fine.
If you ensure that the plaintext-encryption key is independent of the
counter-encryption key, then sure, it's perfectly fine.
It is just one instance of a more general schema: apply any PRF to a
counter, and use the result as your IV. Since any secure block cipher
is also a secure PRF (as long as you don't try to use it for more than
2^32 blocks -- the birthday bound), this is safe.
I suspect you had done a premature optimization, and were thinking of
using the same key for both text-encryption and counter-encryption.
I would advise against that. It voids the security warranty; the proof
of security is no longer valid.
And it's not at all clear that it's safe to use the same key for both
uses. I suspect that this optimization might introduce certificational
weaknesses in some threat models. Maybe the attacks are exotic enough
that they wouldn't be too much of a concern in practice, but you'd have
to do an in-depth analysis of all the attacks. It seems more prudent
to go with the mode that has a proof of security against even exotic
attacks, i.e., independent keying.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: counter as IV?
Date: 8 Aug 2000 21:18:16 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Another thing to consider: Instead of using a simple integeger for your
> counter, what about the state of a LFSR?
If the block cipher is secure against chosen-plaintext attacks, either
method should work just fine.
If the block cipher has some weaknesses against differential
cryptanalysis, then you are right that a LFSR might well be somewhat
preferred over an integer counter. However, I think it is simpler and
safer to just pick a block cipher that resists differential cryptanalysis,
and then not worry about these details. Just my personal opinion...
------------------------------
From: "Dave Foulger" <[EMAIL PROTECTED]>
Subject: Crypto and CCTV
Date: Wed, 9 Aug 2000 11:14:52 +0100
With the rise (especially here in the UK) of public CCTV surveillance I have
been thinking about how encryption systems could help with 2 of the worries
I have.
1) Unauthorised use of CCTV material. (Blackmail, unauthorised release to
press etc.)
2) Tampering with evidence (Given the general poor quality of the video
image and often static background I imagine that the average desktop PC
could now fake video evidence such as pasting someone walking across the
frame or changing the date/time info)
The idea I have in mind would involve encrypting the video as it is recorded
(on digital video tape, recordable dvd or any other medium). I think that
some form of public key system might work.
The public key for encryption would be stored on the video recorder, on a
smart card or something similar so it could be updated if the private key is
compromised) . The private key (or keys if using secret sharing) to decrypt
the video would be held by say one or more senior police officers).
The other half of my idea is the bit I'm still not sure about.
I would like the video recorder to sign and timestamp the video as it is
recorded to prevent forgery.
How do the group feel this could be done? A sealed signing key built into
the recorder?
I realise that it would be hard to prevent a determined forgery of the video
but I would like to make it as difficult as possible within a reasonable
cost.
Anyone got any thoughts? Has such a system been implemented anywhere?
Dave
------------------------------
From: "Darth Maul" <[EMAIL PROTECTED]>
Subject: Re: New Patent to an old machine
Date: Wed, 9 Aug 2000 12:24:19 +0200
"Steve" <[EMAIL PROTECTED]> wrote...
> There is still another machine out there not mentioned in Kahns book
> or here in the previous Patent thread. I'd like to know of its current
> existence.
>
[snip for bandwidth]
You are talking about the KL-7/TSEC (ADONIS), which was hurriedly retired
from service following the unveiling of the Walker/Pelton spy-ring. It is
unclassified, (when sanitized), today. An excellent description with photos
can be found at Jerry Proc's web-site:
http://webhome.idirect.com/~jproc/crypto/kl7.html
>
> Steve
Bjarne
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Physical RNG
Date: Wed, 9 Aug 2000 03:34:33 -0700
Take a few of those AOL CD's you get in the mail and suspend them from
strings. Shine a lamp or two on the scene while a fan blows them around.
Snap a few pictures with you USB webcam. Whiten the results by hashing the
video data.
At least you will have allowed those CD's to serve some useful purpose!
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Ed <[EMAIL PROTECTED]> wrote in message news:8mog8q$adu$[EMAIL PROTECTED]...
> Hello,
>
> I'm searching for a physical random number generator.
> But I've have important constraint :
> - it should be plugged in a PCI bus
> - it should be useable under Solaris system ( or Unix system)
>
> If you know a physical RNG that don't match these criteria,
> it could help me.
>
> Please send any information to : [EMAIL PROTECTED]
>
> Edouard DESSIOUX
> Everbee
>
>
>
>
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: The Feistel network in Twofish
Date: Wed, 9 Aug 2000 12:39:34 +0200
I have been working with the Twofish sourcecode (the one from AES written in
ref. C).
And one thing puzzles me:
In the blockEncrypt function, actually in the main Twofish encryption loop
(after the input whitening), the "heart" of the function is suddenly
seperated with
#if FEISTEL
.
.
#else
.
.
#endif
Why the need for this ?? The Twofish is based on a Feistel structure, so
what good is the code under #else ??
I'm not sure if this is obvious, but if it is, please enlighten me.
Kim
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Authentication
Date: Wed, 9 Aug 2000 04:57:46 -0500
Reply-To: "Rick Braddam" <[EMAIL PROTECTED]>
All the authentication systems I've seen use a pre-arranged exchange of
some secret information. Even SRP requires that the server have a secret
hash value and salt.
Is there an authentication system which has the client send a special --
say encrypted-- value first that the receiver does not have the key to
decrypt/decode, then sends the key?
A primitive example would be for both parties to develop and encrypt a
string with their private key and send it to the other. Then each party
signs the received string and sends it back. Then each party sends the
public key needed to verify the signatures and decrypt the strings to the
other. Neither party sends the public key until they receive the signed
message from the other.
I've thought about this for two days, and didn't see any holes in it. Then
while writing this I realized that a MITM doesn't have to know the
string... he just sends his own to each recipient. The only cure I can see
for it is to use an on-line Video Chat.
At least, it may could be a cure. Consider a Video Chat program will full
PGP capability, adding perhaps all the AES ciphers and blowfish. Two
correspondents initiate a direct client to client chat session and start
authentication. Each gets a dialog box with four rows of hex digits, each
row showing five groups of four digits, and a passphrase entry box. Each
user writes down the hex digits and enters a passphrase. The program
concatenates the user's public key, the correspondent's public key, and
the binary number represented by the hex digits, and encrypts the result
with a key derived from the passphrase, then sends the ciphertext to the
other user, possibly using steganography in the video or audio. Each user
receives a ciphertext from the other, but is unable to decipher it at this
point.
Here's where the video part comes in. Each user holds the paper they wrote
the hex digits and passphrases upon in front of their camera. When they
see the paper the other is holding up, they write down the hex digits and
the passphrase. They enter the passphrase, and the program deciphers the
received ciphertext. The program compares the first public key with the
correspondent's public key, and the second with their own public key, and
displays the hex digits. The user compares the displayed digits with the
ones obtained from the monitor display and written down earlier. If either
the hex digits or the user's public key don't compare correctly,
authentication fails. The user has the option of importing the
correspondent's public key from the ciphertext if it is different from the
one they have. That would be appropriate if and only if they were
expecting a new key.
At this point each user has a public key which they can associate with a
face, a voice, and any information they may have received in the course of
the Chat session prior to starting authentication. A man in the middle
attack is still possible, but it would take an elaborate setup, and either
user could recognize inappropriate behavior of the person they are seeing
or excessive delays between messages sent and responses.
The program could do more than just chat, such as post encrypted or
plaintext messages to newsgroups, email, file transfer, or even web
browsing. It could also incorporate SRP, SPEKE, etc, for cases where that
is more desirable.
There are probably lots of reasons why this won't work. I'm looking
forward to finding out what they are.
Rick
------------------------------
From: ArchimeDES <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Wed, 09 Aug 2000 11:19:18 GMT
On Sun, 6 Aug 2000 18:31:31 -0700, "eboy" <[EMAIL PROTECTED]> wrote:
>I'm a budding shareware author who'd like to code my registration
>keycode generator to use asymmetric encryption (like RSA, with private
>and public keys, but not necessary RSA per se). I figure I shouldn't
>have to worry about keycode generators popping up on cracker sites
>within months of release of my product if I can implement this.
A designer of a protection scheme should be aware of this false sense
of security: you can implement the most solid cryptographic
alghorithm, but if you make something like this->
char *key=GreatCipher(username);
if(strcmp(key, userinput)==0) registered();
else notRegistered();
a newbie cracker will obtain a registered copy of your program in five
minutes.
So, before trying to implement an alghoritm knowing nothing about it,
try to use simple CRC using anti-cracker techniques such as
self-modifing code, integrity check of executable, implementing the
register check function in different manners and calling randomly one
of them frequently, antidebugging, on-the-fly executable compression &
decompression and so on...
Even if you use all of these techniques plus smartcards containing
vital pieces of code of the program, expiring keys of 1Gbit,
fingerprint+voice+face+blood scanning, a motivated cracker will defeat
your locks bypassing them, it's more than fun for him, it's a
religion; they can spend days in front of the monitor without
sleeping and eating only to send you by e-mail his "personal version"
of your program with a WAV of his laugh.
Maybe at that time you could release a new version of yor software
(using a completely different protection scheme obviously) with new
features making the previous obsolete...
ArchimeDES
=============================================================
remove CRYPTO from my address
for e-mail
------------------------------
From: ArchimeDES <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption passes
Date: Wed, 09 Aug 2000 11:19:19 GMT
On Fri, 04 Aug 2000 22:18:18 GMT, AllanW <[EMAIL PROTECTED]> wrote:
[...snip...]
>My proposal is to use more than one pass through the data
>when encrypting it. The first pass would take the plaintext
>and produce the first ciphertext, which I will call C1.
>Nothing in C1 would indicate which algorithm was used to
>create it.
[...snip..]
>Again, nothing in C2 would indicate which type of encryption
>was used. And so on until we feel that the data is secure
>enough.
Security by obscurity?
Hmmm, the security of a cryptosystem is not given by the secrecy of
the algorithm used, only by the secrecy of the key (Principle of
Kerckoffs).
ArchimeDES
=============================================================
remove CRYPTO from my address
for e-mail
------------------------------
From: Michael Portz <[EMAIL PROTECTED]>
Subject: Re: Using 256bits key for IDEA?
Date: Wed, 09 Aug 2000 12:11:56 +0200
Vincent Bouret wrote:
>
> Hello,
>
> Will it be more secure to use a 256 bits key with IDEA? I would change the
> key generation part to deal with 256 bits but I would like to know for how
> much bits should I rotate the key (in the original 128bits version it's 25)
> but with 256 bits I guess that must be higher.
>
> I am also wondering when I need to swap the 16bits inner blocks in the algo.
> In AC (Applied Crypto) from Bruce Schreiner there's a mistake with the test
> data (the blocks are never swapped).
>
> I read you have to swap them each round excepted for the last. Is it true?
> And what about the decryption part?
>
> Thank you
>
> Vincent
Well..dang..cant find my copy of the excerpt of Lais dissertation
and strange enough I dont find the fact mentioned in Bruces book.
But I am quite sure that IDEA was designed to be very flexible on
the keysize. 128Bit was just considered enough at this time. Iff
I am not utterly wrong I suggest that you at least check what the
designers say about extending the keysize.
Good Luck
Michael "I Know the Copy MUST be Somewhere" Portz
--
/ 3C Dr.Klingler, Dr.Portz GbR
/ Kaiserstr. 100 (TPH III)
/ 52134 Herzogenrath / Germany
/ Tel/Fax: ++49 2407 96-056/-292
/ Email: mailto:[EMAIL PROTECTED]
/ WWW: http://www.3CKP.com/
/ GNU-PG Fingerprint: 3001 5237 D60F 2B3F 1049 EF35 CD00 52EC 802B 91D6
/ GNU-PG Key: http://www.3CKP.com/3C-GPG-Portz.asc
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Software license software with PK ????
Date: Wed, 09 Aug 2000 11:52:10 GMT
Hi All
My background is the need for a good public key library implementation to
do software license software (will make a hackers key-generator useless). I
am unable to use RSAREF because it output the same size (crypt text) as
the modulus size, and this make the output far too big compared to my
needs (if I like to make it secure)
I need a public key encryption algorithems that maintain the same size
public encrypted as decrypted (as with most block cifers).
The plain text document will be known, and also the public key will be
known. Then a test will see if the encrypted version match the plain text
version.
I do not know if this is possible in some way with Elliptic Curve
cryptography or other PK algorithems?
Thanks
Benny Nissen
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Wed, 09 Aug 2000 11:52:10 GMT
Hi Ed
I actually have been working with something like this for some time now.
Not as easy as you think. I have implemented RSA and the main problem is the
output of the algo.
If it is intended to be secure the output also get to become very long 1024
bit for example even if the input is short.
This is not a very good output if you need to distribute a simple key (hex
or base64 encoded). In this case the outpuot need to be distributed as a
file to be imported in the protected program.
I am still loking around for a good solution.....
Benny
"eboy" <[EMAIL PROTECTED]> skrev i en meddelelse
news:[EMAIL PROTECTED]...
> I'm a budding shareware author who'd like to code my registration
> keycode generator to use asymmetric encryption (like RSA, with private
> and public keys, but not necessary RSA per se). I figure I shouldn't
> have to worry about keycode generators popping up on cracker sites
> within months of release of my product if I can implement this. One
> shareware FAQ said doing this wasn't that hard a thing to do. (?)
> Anyway, while I know a little about the math theory behind this
> encryption, programming it is in another ballpark from where I'm
> playing. Can anyone point me to some reference that would be helpful for
> a non-math-genius, non-super-geek programmer to accomplish this? (I have
> PGP's source code - there isn't enough time in the universe for someone
> like me to decipher it) (without help).
>
> I guess what I'm looking for is a basic programming algorithm (perhaps
> in pseudocode to just illustrate each step) for encoding and decoding
> some plain text using the primes, plus some details about how to
> generate the monster primes themselves. I was thinking I could just use
> PGP to generate a couple of 2048 bit primes and use those but I can't
> find a way to get PGP to tell me what *both* primes are when it
> generates a public and private key pair for me. If anyone can guide me
> just in this, it would still be a big help...
>
> thanks,
> ed
>
>
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: counter as IV?
Date: 9 Aug 2000 11:42:42 GMT
David Hopwood <[EMAIL PROTECTED]>:
>> If the first plaintext block to be CBC encrypted cannot depend on the
>> IV, then we're safe (assuming IVs that are pseudo-random in a weak
>> sense -- roughly, XORs of IVs may not coincide with XORs of plaintext
>> blocks); [...]
> Nearly but not quite: if, for example, the first n blocks are known and
> the (n+1)th block is chosen with knowledge of the IV, that allows the
> same attacks.
How? Knowledge of the first plaintext blocks does not imply knowledge
of the corresponding ciphertext blocks if the key is unkwown and the
IV has not been used before.
> Also, if an attacker can see a ciphertext and then choose the following
> plaintext block, the same attacks are possible as if the IV were
> predictable.
Good point, you are right (each ciphertext block serves as IV for the
remaining part of the encryption). I was implicitly assuming that
encrypting a number of blocks would be finished before any of the
resulting ciphertext blocks would be published (with any later
encryptions depending on a totally new IV). In your attack model,
things are actually quite simple: CBC is insecure.
------------------------------
** 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
******************************
