Cryptography-Digest Digest #450, Volume #13 Wed, 10 Jan 01 12:13:01 EST
Contents:
Re: secure RNG (Peter Gutmann)
Re: Bluetooth security? (Arthur Dent)
New stream cipher ([EMAIL PROTECTED])
Re: DES validation ("kihdip")
Re: New stream cipher (Ichinin)
Re: Comparison of ECDLP vs. DLP (Bob Silverman)
Re: New stream cipher (Simon Johnson)
Re: New stream cipher (Simon Johnson)
Golic ("kihdip")
Re: Hash/Message digest vs Signature vs MAC? ("Ingmar Grahn")
Re: Crypto Conferences ("Jakob Jonsson")
Re: Golic (Thomas Pornin)
Re: New stream cipher (John Savard)
RE-X-POST Quick-and-Dirty demonstration of twarting US6006328 ("Thomas J. Boschloo")
Re: Crypto Conferences (Quisquater)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: secure RNG
Date: Wed, 10 Jan 2001 13:22:32 -0000
"Dobs" <[EMAIL PROTECTED]> writes:
>I am looking for good random number generator which can be used in
>cryptography, ( for example in key generating) . If anybody knows where I
>can find such a secure generators implemented in C ( not in Visual C :),
>Could You please write me back or send it to me. I need 3,4 or 5 such a
>generators to compare. I would be greatful for help:))))
There are quite a few of these around, I have a fairly detailed analysis of
requirements and existing generators used in /dev/random, PGP 2.x/5.x, ssh,
SSLeay/OpenSSL, Fortezza, and some others in (from memory) Chapter 7 of my
thesis, available from http://www.cs.auckland.ac.nz/~pgut001/thesis/.
Peter.
------------------------------
From: Arthur Dent <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 13:50:02 +0100
On Wed, 10 Jan 2001 12:16:27 +0100, "Ingmar Grahn" <[EMAIL PROTECTED]>
wrote:
>
>> from what i hear there are some discussions about extending
>> security. but cannot go into detail here.
>
>You say there are some discussions about extending the Bluetooth security?
>Could you be a bit more specific about this? I just e-mailed Markus
>Jakobsson at Bell-labs (who's one of the authors of "Security Weaknesses in
>Bluetooth") asking if he knew if any of the weaknesses found in the v1.0B
>standard of Bluetooth was to be corrected in v1.1. But he said that the
>flaws were still present in this version. Isn't this extended security
>you're talking about supposed to be released until the v2.0 standard? And
>anyway, what will this extended security consist of?
i heard about talks of an updated connection and transmission security
between bell & a french based smartcard company for V2.
hope this helps you but i cannot go into more detail right now, sorry.
but if you have good contacts to bell, maybe they can tell you more.
------------------------------
From: [EMAIL PROTECTED]
Subject: New stream cipher
Date: Wed, 10 Jan 2001 13:38:58 GMT
Stream Cipher using AOTP-8 Approach
An objective of this design is to get strong stream cipher
with high possible performance using quasi One Time Pad approach.
To achieve this we decided to avoid using multiplication operations.
For simplicity we are using here abbreviation OTP meaning always
quasi One Time Pad.
The main idea of this algorithm is intentional lose of 50%
of information during pass from one state to the next one.
So this algorithm is implementation of one-way function, which maps
a finite sequence of byte (Key) to a probably infinite sequence of
quasi-random bytes.
Encryption and decryption implements the same procedure, which XOR's
input with OTP to get output.
To get some imagination about performance of the algorithm
1677721600 bytes was sent to encryption in a loop on my PC,
which takes 98 seconds and makes 16 Megabyte/sec.
Statistical analysis shows, that probability to find byte in an OTP
sequence is 0.0039x for any value in the range 0-255,where 'x'
represents variable value, which changes from one state to another.
We would like to introduce term Key Avalanche Effect. Key Avalanche
Effect answers a question how many bits are changed in generated OTP
if only one bit of Key is changed. In our case it is 50%.
Algorithm description in pdf and source code can be download at
www.alex-encryption.de
Please follow links for AOTP-8 at the end of download list.
Have fan.
Alex.
P.S. The sacramental question "Do we need AES?" I would like to answer
Yes/NO.
Yes- while AES winner is well designed and strong enough.
No- while AES winner doesn't cover all needs.
This is why I do not appreciate Bruce Schneier's skepticism regarding
IBM attempts to develop new encryption algorithms. No one can kill
progress
in cryptography.
What do you think about?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: DES validation
Date: Wed, 10 Jan 2001 14:50:04 +0100
Try
http://csrc.nist.gov/nistpubs/800-17.pdf
At page 134 you'll find round results.
Kim
<[EMAIL PROTECTED]> wrote in message news:93hlq0$k41$[EMAIL PROTECTED]...
> Hi all
>
> Does anyone have some test vectors for DES. What a i really need is
> each of the keys used in each round...and some intermediate values for
> the first couple of rounds (like before sbox, after sbox). A single set
> of key,plaintext and ciphertext will do but more than one would be nice
>
> Thanks
>
> Jonathan
>
>
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Wed, 10 Jan 2001 13:56:37 GMT
> So this algorithm is implementation of one-way function,
> which maps a finite sequence of byte (Key) to a probably
> infinite sequence of quasi-random bytes.
PRNG?
> Key Avalanche Effect answers a question how many bits are
> changed in generated OTP if only one bit of Key is changed.
> In our case it is 50%.
Simpler:
Create a streamcipher where
K´ = Hash(K + Feedback)
Common hash algorithms already have such characteristics
built in and are one way, why reinvent the wheel?
Regards,
Ichinin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Wed, 10 Jan 2001 14:29:59 GMT
In article <[EMAIL PROTECTED]>,
see.signature wrote:
>
> I stand by my assertion that there's no reason why a security proof
must
> always involve unproven assumptions (of the latter sort).
Indeed. The best security proof one could ever hope for would be
a proof of a lower bound on the complexity (both time and space)
for breaking an algorithm. The only assumption needed would be a
bound on computer resources. No "reduction to an equivalent problem"
would be involved.
It is clear that time/space issues can not be separated. Any
algorithm can be broken in time O(1) if enough space for suitably
large lookup tables is available.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Wed, 10 Jan 2001 14:36:35 GMT
In article <93holh$mek$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Stream Cipher using AOTP-8 Approach
>
> An objective of this design is to get strong stream cipher
> with high possible performance using quasi One Time Pad approach.
> To achieve this we decided to avoid using multiplication operations.
> For simplicity we are using here abbreviation OTP meaning always
> quasi One Time Pad.
> The main idea of this algorithm is intentional lose of 50%
> of information during pass from one state to the next one.
> So this algorithm is implementation of one-way function, which maps
> a finite sequence of byte (Key) to a probably infinite sequence of
> quasi-random bytes.
> Encryption and decryption implements the same procedure, which XOR's
> input with OTP to get output.
> To get some imagination about performance of the algorithm
> 1677721600 bytes was sent to encryption in a loop on my PC,
> which takes 98 seconds and makes 16 Megabyte/sec.
> Statistical analysis shows, that probability to find byte in an OTP
> sequence is 0.0039x for any value in the range 0-255,where 'x'
> represents variable value, which changes from one state to another.
> We would like to introduce term Key Avalanche Effect. Key Avalanche
> Effect answers a question how many bits are changed in generated OTP
> if only one bit of Key is changed. In our case it is 50%.
>
> Algorithm description in pdf and source code can be download at
>
> www.alex-encryption.de
>
> Please follow links for AOTP-8 at the end of download list.
>
> Have fan.
> Alex.
>
> P.S. The sacramental question "Do we need AES?" I would like to answer
> Yes/NO.
> Yes- while AES winner is well designed and strong enough.
> No- while AES winner doesn't cover all needs.
> This is why I do not appreciate Bruce Schneier's skepticism regarding
> IBM attempts to develop new encryption algorithms. No one can kill
> progress
> in cryptography.
> What do you think about?
>
> Sent via Deja.com
> http://www.deja.com/
>
I've looked at your paper, some aspects are confusing. But there are
some error i'd like to point out now:
"So this algorithm is an implementation of a one-way function that maps
a finite sequence (KEY) to probably an infinite amount of quasi-random
bits"
I can tell you now it won't be infinite. A computer has a finite number
of states, and any machine that does have a finite number of states
will cycle eventually. Granted the cycle length may be large but never
try and say its infinite.
"It is impossible to predict, which permutation permtab represents
during encryption"
Well this is a contradiction. If i have the key, i can iterate this
stream cipher forward and therefore predict what permtab represents
quite easily (obvious, otherwise i can't decrypt my cipher-text)
If i couldn't, this would make a totally determistic algorithm produce
completly random-bits.
As for the algorithm, i'm not sure what to make of it. However one
particular point you make may show weakness:
"We would like to introduce Key Avalanche Effect. Key Avalanche
effect answers the question how many bits are changed in the generated
OTP if one bit of the key is changed. In our case it is 50%"
Well, what exactly does this mean?
Does it mean if i change the key by one bit, half the message is
decrypted and the rest is garbage? Well, if you can say with absolute
exactness that half the bits will remain the same with a flipping of a
single bit of the key then a differential attack can probably launched
against it. Actually, i might not even need to do that. If i flip two
of the key bits do 25% of the bits remain in tact? If this is also
true, then i could probably build an algorithm to find the key that
works on trial and error.
Here are a few questions i ask:
Can you justify your claims that the cycle length is indeed large?
And could you clear up that permtab function a bit, prehaps a worked
example on a smaller array size would help?
Also you say that you lose half you 50% from the transistion from one
state to the next, this probably means that you lose a substiantial
amount on entropy from the internal state each iteration. How do
prevent this?
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Wed, 10 Jan 2001 14:53:12 GMT
In article <93hpmg$nej$[EMAIL PROTECTED]>,
Ichinin <[EMAIL PROTECTED]> wrote:
>
> > So this algorithm is implementation of one-way function,
> > which maps a finite sequence of byte (Key) to a probably
> > infinite sequence of quasi-random bytes.
>
> PRNG?
>
> > Key Avalanche Effect answers a question how many bits are
> > changed in generated OTP if only one bit of Key is changed.
> > In our case it is 50%.
>
> Simpler:
> Create a streamcipher where
> K´ = Hash(K + Feedback)
>
> Common hash algorithms already have such characteristics
> built in and are one way, why reinvent the wheel?
>
> Regards,
> Ichinin
>
> Sent via Deja.com
> http://www.deja.com/
>
The security of this depends on the has, of course. But the main point
is that Hashes do not have to be secure against linear cryptanalysis
(it not a viable attack against them) but stream-ciphers can be
attacked by linear cryptanalysis. It not safe to assume the designers
anticipated the hash's use as a stream cipher, therefore for complete
security, i wouldn't use a hash.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Golic
Date: Wed, 10 Jan 2001 16:30:35 +0100
Does anyone have a link to the paper "Cryptanalysis of alleged A5 stream
cipher" by J. Dj. Golic ??
(Proceedings of Eurocrypt '97)
Kim
------------------------------
From: "Ingmar Grahn" <[EMAIL PROTECTED]>
Subject: Re: Hash/Message digest vs Signature vs MAC?
Date: Wed, 10 Jan 2001 16:35:18 +0100
> The key in the MAC ensures that the sender is the one he claims to be.
> Normally you encrypt your data and then uses a hash algorithm to
> authenticate it and not the other way round.
> In IPSec for instance, a index number (SPI) is used to tell the receiver
> about the transmission. This number cannot be encrypted, but you'll need
the
> authentication.
As I interpret it the protocol is something like this:
1. M is encrypted (by using the receivers public key).
2. A MAC is calculatde using the encrypted message M and the key K
identifying the sender.
3. The recipient receives the message. Calculates the MAC himself using the
same input (the encrypted message M and the key K identifying the sender)
4. If the MAC:s are the same, the message actually is from the sender, and
it hasn't been tampered with on the way.
5. The recipient decrypts the message using his private key.
But how does the recipient know that the key he used to calculate the MAC
actually corresponds to the sender? How can that verify the sender?
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Crypto Conferences
Date: Wed, 10 Jan 2001 13:27:10 +0100
Visit Anne Canteaut's web site:
http://www-rocq.inria.fr/codes/Anne.Canteaut/annonces.html
Jakob
<[EMAIL PROTECTED]> skrev i meddelandet
news:93hejg$eta$[EMAIL PROTECTED]...
> Hi,
>
> I am looking for the major conferences on cryptography and smart card
> security (Names, dates and web sites).
>
> Regards,
>
> Brice.
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Golic
Date: 10 Jan 2001 15:44:00 GMT
According to kihdip <[EMAIL PROTECTED]>:
> Does anyone have a link to the paper "Cryptanalysis of alleged A5 stream
> cipher" by J. Dj. Golic ??
Try http://www.attrition.org/~wrlwnd/crypto/cryptanalysis/a5-hack.htm
(next time, try the http://www.google.com/ search engine: it is good)
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New stream cipher
Date: Wed, 10 Jan 2001 15:47:22 GMT
On Wed, 10 Jan 2001 13:38:58 GMT, [EMAIL PROTECTED] wrote, in
part:
>The main idea of this algorithm is intentional lose of 50%
>of information during pass from one state to the next one.
>So this algorithm is implementation of one-way function, which maps
>a finite sequence of byte (Key) to a probably infinite sequence of
>quasi-random bytes.
But if you keep losing information, then your remaining fraction of
the initial key keeps shrinking. So after a while, you might wind up
with one of a limited number of stream cipher sequences, it seems.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.binaries.cracks
Subject: RE-X-POST Quick-and-Dirty demonstration of twarting US6006328
Date: Wed, 10 Jan 2001 17:09:34 +0100
Introduction, US6006328 is a patented methode of tamper protecting
software and defeating key-loggers. Netsafe AKA ExeGuardian is an
exe-wrapper which uses TripleDES. Sorry, no .nfo file, I am a freelance
old-style 8086 only cracker :-( I never believed in Windows and thus
never spend much time on it.
Imad wrote:
>
> Hello Thomas,
>
> I don't think you are going to hear from Chris any time soon.
>
> Well, at least no till he patents your crack to his snake oil.
>
> LOL
Hey, THANKS ;-) I don't think he has anything to patent my crack
however, because I was careful to not give him any clue on how I did
this. Basically he traps INT 21h/4Ch (end program, it would have been
smarter to trap INT 20h because that is what INT 21h/4Ch calls upon
exit, but Chris probably doesn't know this <g>). Well, Chris is stupid
enough to believe PGP has ended when it gets a INT 21h/4Ch and it will
nicely uninstall itself <double g>. What he could have done is display a
message like "Netsafe 4.2 has ended" upon exit (this is described in his
patent, he called this his 'visual cue' and it is supposed to be a
complex rendered 3D animation that is impossible to copy by a cracking
utility like mine). It could also use a 'beep' to show it had ended so
the user could see the change in the way the interface works when my
program 'kicks' the protection. Or the user could run a keylogger
utility and make sure afterwards that no sensitive information entered
its log file. That would only mean I had to rip his 3D code, print a
line, implement some keylogger protection myself or just let the Netsafe
code think it is in control when it is not.
You do know 386 code and you have nice debuggers, don't you? I always
thought very highly of you with you PGP Disk patches, chosen keyID
utilities and things like that. Maybe you could rip the 386 MS-DOS code
of Screen Thief <http://www.villa.nildram.co.uk/download.htm>. It
somehow redirects IRQ 1 (the keyboard interrupt signal line) to another
interrupt and makes it call the interrupt 9 Chris traps in his code (by
peeking into the interrupt table at offset 0:24 length 4). Chris would
be too stupid to notice the difference and he has no knowledge on how to
twart this. This would be the ultimate keylogger that *works under DOS*.
I checked Screen Thief under DOS (freeware since 1998), and it's
wake-up key mechanism works inside Netsafe's PGP wrapper. Only while
Screen Thief keeps functioning nicely, Netsafe crashes because of this.
Only goes to show how much Chris's code sucks. There must be some bugs
in it due to his stupid undocumented functions he uses (like CS:IP being
on the stack on execution, MS-DOS probably starts a program (INT
21h/4B00h) by pushing the starting address (from the EXE header) and
doing a RETF (return FAR).
Well, I have a new signature as you can see ;-) Here is a batch-file to
use it with:
*** test.bat ***
@echo off
goto test
d40:1el20
q
:test
t-unsafe
pgp -c t-unsafe.com
debug <test.bat
*** end test.bat ***
The program is not as beautiful as the program I posted on sunday and
yesterday evening, but it will really make Chris Drake (the inventor of
Netsafe and ExeGuardian) jump through a window, I'm sure.
Have fun with it, but don't come complaining if it has unknown side
effects. You had best kill your MS-DOS box after using it and confirming
that the protection has been broken by using the above batch file. The
crack is really quick and dirty and might not work with all wrapped
programs.
Regards!!!
Thomas
(Feel free to ask for the original executable which is cleaner and more
specific, this one was written to get through Deja's stupid moronic
filters, let's hope it works. You can contact me at boschloo<at>
multiweb.nl and you can even download my key from a server for a private
conversation).
--
=====BEGIN PGP MESSAGE=====
Comment: This signed executable will twart Netsafe 4.2
Comment: Try Netsafe at <http://www.ozemail.com.au/~netsafe>
owEBzQAy/4kAeQMFADpc/IoBD9pfIlygCQEBvXYDHjqpd4mblDvTxQsubVPZAhEL
21LgMaNgT5rE9+Te4zLxaC4XpcnC7uMXSMPDWOPGHCijf9J2jo9HdrYsjQWPWUXH
JgwazJ88Df13S3QG8R3+i+uxtGxCG6OPr94nLSbdfcrO/6isT2IMdC11bnNhZmUu
Y29tAAAAAOsjLoA+/wAAdAHPgPwwdRBQLv4G/wC0TM0hLv4O/wBYLv8uXAC4ITXN
IYkeXACMBl4AtCW6AgHNIbIlzSc=
=3E5B
=====END PGP MESSAGE=====
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Crypto Conferences
Date: Wed, 10 Jan 2001 18:27:50 +0100
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I am looking for the major conferences on cryptography and smart card
> security (Names, dates and web sites).
>
> Regards,
>
> Brice.
>
> Sent via Deja.com
> http://www.deja.com/
See http://uclcrypto.org/call_for_papers.html
and
http://www.iacr.org/events/index.html
(not only the major conferences).
For smart cards:
see http://cardis.org (in the future)
and
http://www.ece.wpi.edu/Research/crypt/ches/
------------------------------
** 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
******************************
