Cryptography-Digest Digest #319, Volume #12 Mon, 31 Jul 00 10:13:00 EDT
Contents:
Re: Psuedo-random number generation (Mack)
Re: How secure is Pegwit? ([EMAIL PROTECTED])
Re: Password Protected Documents ("Lyalc")
Re: About DES Key Schedule function (John Savard)
Re: Small block ciphers (Mok-Kong Shen)
unbreakable code? ("Graham Orme")
Re: Walter Mathau a cryptographer?? (Serge Paccalin)
Re: Password Protected Documents (Runu Knips)
Re: unbreakable code? (jkauffman)
Re: Walter Mathau a cryptographer?? ([EMAIL PROTECTED])
Re: unbreakable code? (John Savard)
Re: Walter Mathau a cryptographer?? (John Savard)
Re: unbreakable code? ("Trevor L. Jackson, III")
Re: Encrypt string to produce a unique number ("Trevor L. Jackson, III")
Re: BUGS v3.3.0 - CONTEST (Sylvain Martinez)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 31 Jul 2000 07:12:59 GMT
Subject: Re: Psuedo-random number generation
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Well I'm looking for a bit of brief help. I'm working on a one-time
>pad system and I'm trying at the moment to devise a method to get
>identical sequences of completely random numbers to two different
>people without the possibility of compromise. The only two methods
>I've realized are particle entanglement (obviously a bit impossible
>right now) and trading CDs. Well short of setting up a hardware,
>random number generator in my house (which i plan on doing) I need to
>fill a few CDs with random bits.
>
>Right now, for testing, I'm willing to fall back upon
>psuedo-randomness, but I'd rather be developing my software than a
>program I will use very briefly and never again. So...
>
>If anyone knows of a good program which generates numbers with a high
>degree of randomness and can do so on the scale of 650megs within a
>realistic ammount of time, PLEASE LET ME KNOW! Even if it takes a
>few days or longer I'm interested as I'm still developing the
>interface and have time to kill.
>THANKS.
>
>BTW - Please post a followup and do not email me at this time.
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
>
>iQA/AwUBOYUfDBJETAFqh0RgEQISUACeIcFNv5t7oJ18Jq+h1WrlS6OmHtEAoKhx
>z7XKEmlcDHR56c18UR+pGRGH
>=M4Gy
>-----END PGP SIGNATURE-----
>
650meg/day = 8k/sec
I believe diehard comes with a program that will combine
files in an xor manner. Take a sound sample and compress
it with a CRC. CRC-32 over 128 bytes at a time is what I use.
Repeat till you have a big enough file.
Encrypt with your algorithm of choice.
Encrypt with RC4 or ISSAC.
Then do the same thing with a second file of the same type
and Xor them together.
Discard a bit at the front of the final file (about 2k).
Note use different passwords for each encryption.
This method will only net you about 1300 bytes/sec.
(The sample rate is assumed 44k/sec with 16 bit sampling
and mono input with 32 times compression with CRC)
So you are still looking at about six days / CD.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Crossposted-To: alt.security.pgp
From: [EMAIL PROTECTED]
Subject: Re: How secure is Pegwit?
Date: Mon, 31 Jul 2000 07:20:06 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Ed Suominen wrote:
> 3. In Pegwit, your passphrase *is* your private key.
actually the private key = SHA1(passphrase)
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOYUMdTBaTVEuJQxkEQINeQCg1hNYsVG49C10UZdipGC4zI+M01AAoI+n
XkZxsQOetePA+CWZxxOjE0ov
=G7ZY
=====END PGP SIGNATURE=====
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Password Protected Documents
Date: Mon, 31 Jul 2000 18:05:46 +1000
What's to stop a complete cut'n'paste for the document content into a clean,
unprotected document?
Lyal
Arfy Woof wrote in message <[EMAIL PROTECTED]>...
>I've written an editing program in c++ that generates documents ala
>Word. I need to implement password protection capabilities on the
>documents, but only write/edit protection. (I still want everyone with
>the program to be able to open/view the file, but if a password is
>set, then they should not be able to edit the file).
>
>I've been using the SHA algorithm to encrypt the password, but how
>would I store this within the document without being obvious? It
>would seem fairly easy for someone to just "cut out" the encrypted
>password, rewrite a new file and gain full editing capabilities. I
>can't encrypt the entire file, because that wouldn't allow access for
>people who just want to view the file. Any suggestions? I realize
>nothing is 100% safe, I just want to make it as difficult as possible
>for shlubs to hack into the documents.
>
>Thanks for any help
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: About DES Key Schedule function
Date: Mon, 31 Jul 2000 08:17:00 GMT
On Sun, 30 Jul 2000 21:14:18 GMT, Garba <[EMAIL PROTECTED]>
wrote, in part:
>Maybe it's a stupid question, but I haven't understood if in Key
>Schedule function in Des the left shifts are "real" logical shifts (*2
>operations) or rotations.
They are rotations. That way, one has good bits instead of zeroes all
the way through.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Mon, 31 Jul 2000 10:44:33 +0200
Mack wrote:
> But if we use a 12 bit key we now have 8 equations in
> 12 variables. This is obviously not soluble with only one
> ciphertext. If each nonlinear term is a 'variable' we now have
> 4095 unknowns. This would require at least 512 pairs.
> Since the maximum is 256 pairs it can't be solved under
> this assumption.
On what basis can/should one regard each non-linear term as a
(independent) variable? Further, there can be non-linearity of
different nature, so that a 'general' treatment of solutions may not
be practical, I suppose. It seems also to be not clear with your
'solvability with only one ciphertext'. The opponent is normally
assumed to have quite a lot more materials to work with.
M. K. Shen
------------------------------
From: "Graham Orme" <[EMAIL PROTECTED]>
Subject: unbreakable code?
Date: Mon, 31 Jul 2000 08:45:14 GMT
My apologies if this is old, but this seems to be a technique that creates
an encryption that cannot be decoded. This is because there is a key for
every permutation of the encrypted message, so one can make it into anything
at all.
This example works on 1000 digit blocks of numbers, which might be for
example ascii. John and Mary wish to exchange messages. First, John sends by
some secure method a (for example) 10,000 digit number perhaps by meeting or
by courier. Mary now has the 10,000 digit number, called A. John then
composes a password of 10,000 digits called B and subtracts A from it and
send this to Mary. Mary receives B-A and because she knows A now knows B but
no eavesdropper can know B or A which can be any possible 10,000 digit
numbers. Mary gets another 10,000 digit number called C perhaps randomly and
subtracts B from it, and sends C-B to John. Of course an eavesdropper cannot
know C or B from the number sent. They continue in this way until they have
enough secure passwords. Note that if someone learned A they could find out
the rest, so the security hinges on A being secure.
John and Mary now want to send 1000 digit numbers to each other, which
might be ascii messages or anything else. John's first message is called Z.
John takes the first 1000 digits of B and subtracts it from the message Z,
then takes the next 1000 digits of B and add it to Z, then the next 1000
digits and subtracts it from Z and so on until the 10,000 digits of B are
used. John sends this message and Mary decodes it since she knows B. Mary
composes a message Y and encodes it with the password C as before which John
knows how to decode. They can continue like this forever wthout any
eavesdropper being able to decipher any message, since each possible 1000
digit number can be gotten from a corresponding 10,000 digit number. One
therefore cannot narrow down what the 1000 digit message to any less than
all the possible numbers up to 1000 digits long. The password could be less
than 10,000 digits and still be secure, and might even be ok at 1,000
digits.
Any flaws in this?
------------------------------
From: Serge Paccalin <[EMAIL PROTECTED]>
Subject: Re: Walter Mathau a cryptographer??
Date: Mon, 31 Jul 2000 10:42:17 +0200
On/Le Mon, 31 Jul 2000 03:52:27 GMT, [EMAIL PROTECTED] wrote/a
écrit
in/dans sci.crypt...
> Back when Walter Mathau passed away, I was half listening to an obit
> while driving home from work. As usually happens, out of the "corner of
> my ear" I could have sworn I heard them say that Mathau was a
> cryptographer duing WWII and won an medal or commendation or something.
> I never heard anything else about it in any other obit and haven't found
> any info concerning this on the web.
They might have been talking about Hedi Lamarr:
http://web.mit.edu/invent/www/inventorsI-Q/lamarr.html
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypothèse la plus élaborée ne saurait remplacer
_/___(_) la réalité la plus bancale. -- San-Antonio (1921-2000)
------------------------------
Date: Mon, 31 Jul 2000 13:54:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Password Protected Documents
Arfy Woof wrote:
> I've written an editing program in c++ that generates documents ala
> Word. I need to implement password protection capabilities on the
> documents, but only write/edit protection. (I still want everyone with
> the program to be able to open/view the file, but if a password is
> set, then they should not be able to edit the file).
>
> I've been using the SHA algorithm to encrypt the password, but how
> would I store this within the document without being obvious? It
> would seem fairly easy for someone to just "cut out" the encrypted
> password, rewrite a new file and gain full editing capabilities. I
> can't encrypt the entire file, because that wouldn't allow access for
> people who just want to view the file. Any suggestions? I realize
> nothing is 100% safe, I just want to make it as difficult as possible
> for shlubs to hack into the documents.
Then store the documents on a different user than the ones which only
should view them, and deny write access.
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: unbreakable code?
Date: Mon, 31 Jul 2000 04:44:59 -0700
In article
<u0bh5.16860$[EMAIL PROTECTED]>, "Graham
Orme" <[EMAIL PROTECTED]> wrote:
> My apologies if this is old, but this seems to be a
> technique that creates
> an encryption that cannot be decoded. This is because
> there is a key for
> every permutation of the encrypted message, so one can
> make it into anything
> at all.
> This example works on 1000 digit blocks of
> numbers, which might be for
> example ascii. John and Mary wish to exchange
> messages. First, John sends by
> some secure method a (for example) 10,000 digit number
> perhaps by meeting or
> by courier. Mary now has the 10,000 digit number,
> called A. John then
> composes a password of 10,000 digits called B and
> subtracts A from it and
> send this to Mary. Mary receives B-A and because she
> knows A now knows B but
> no eavesdropper can know B or A which can be any
> possible 10,000 digit
> numbers. Mary gets another 10,000 digit number called
> C perhaps randomly and
> subtracts B from it, and sends C-B to John. Of course
> an eavesdropper cannot
> know C or B from the number sent. They continue in
> this way until they have
> enough secure passwords. Note that if someone learned
> A they could find out
> the rest, so the security hinges on A being secure.
> John and Mary now want to send 1000 digit numbers
> to each other, which
> might be ascii messages or anything else. John's first
> message is called Z.
> John takes the first 1000 digits of B and subtracts it
> from the message Z,
> then takes the next 1000 digits of B and add it to Z,
> then the next 1000
> digits and subtracts it from Z and so on until the
> 10,000 digits of B are
> used. John sends this message and Mary decodes it
> since she knows B. Mary
> composes a message Y and encodes it with the password
> C as before which John
> knows how to decode. They can continue like this
> forever wthout any
> eavesdropper being able to decipher any message, since
> each possible 1000
> digit number can be gotten from a corresponding 10,000
> digit number. One
> therefore cannot narrow down what the 1000 digit
> message to any less than
> all the possible numbers up to 1000 digits long. The
> password could be less
> than 10,000 digits and still be secure, and might even
> be ok at 1,000
> digits.
> Any flaws in this?
What you've described is a one time pad. Unfortunately
you've broken the golden rule of one time pads and used it
twice. Once to encrypt a message and again to send a new
otp. The otp itself, used once, is perfectly secure
because all you know is that you're looking for a key (a
pad) that decrypts to say an English text message. The
problem is that any message of the right length is equally
likely, so the attacker is stuck.
The method you describe gives the attacker an advantage if
he knows the history of the conversation, because he is now
not only looking for a key that decrypts the message to
English, but also one that, added to the last encrypted key,
decrypts the last message to English.
It's also highly vulnerable to known-plaintext attacks, and
would become less secure over time for this reason.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Walter Mathau a cryptographer??
Date: Mon, 31 Jul 2000 13:01:19 GMT
Thanks for your response. But no, I don't think so.
I distinctly remember the words "code breaker" (which is what caused my
ears to perk up). The Lamarr "invention" dealt with sub warfare and, as
I recall the story even Hedi Lamarr herself admitted her input into it
was minimal.
In article <[EMAIL PROTECTED]>,
Serge Paccalin <[EMAIL PROTECTED]> wrote:
>
> They might have been talking about Hedi Lamarr:
> http://web.mit.edu/invent/www/inventorsI-Q/lamarr.html
>
> --
> ___________
> _/ _ \_`_`_`_) Serge PACCALIN
> \ \_L_) [EMAIL PROTECTED]
> -'(__) L'hypothèse la plus élaborée ne saurait remplacer
> _/___(_) la réalité la plus bancale. -- San-Antonio (1921-2000)
>
--
"Wife who put husband in doghouse, soon find him in cathouse."
-- Wisdom of the Tao
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: unbreakable code?
Date: Mon, 31 Jul 2000 13:09:28 GMT
On Mon, 31 Jul 2000 08:45:14 GMT, "Graham Orme"
<[EMAIL PROTECTED]> wrote, in part:
>My apologies if this is old, but this seems to be a technique that creates
>an encryption that cannot be decoded. This is because there is a key for
>every permutation of the encrypted message, so one can make it into anything
>at all.
>Any flaws in this?
Basically, the system that has no flaws is: John secretly hands Mary a
10,000 digit number, and then they use it to transmit exactly 10
blocks of 1000 digits in either direction, each time using a different
part of the 10,000 digit number.
Anything else has flaws.
You could use the 10,000 digits as a one-time-pad to send another
one-time-pad, and then use the second one-time-pad instead, which is
your first step.
But then you use your second one-time-pad ... well, your second
additive pad, since you aren't using it just one time ... *both* for
sending messages and for sending your third one-time-pad. This lets
you make a third and fourth pad and so on.
What happens, therefore, is that after you've sent a bunch of pads, it
is true that an attacker doesn't know any of the digits in any of
them. But the attacker DOES know the relationship between each pad and
the next one, because those relationships are the cipher messages
you've sent.
So, if you use the digits in order, he compares message N and message
N+10 (where each message is a single block) and he does have something
to work with, because applying the key by subtracting doesn't hide the
relationships between key blocks very well.
John Savard
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Walter Mathau a cryptographer??
Date: Mon, 31 Jul 2000 13:14:20 GMT
On Mon, 31 Jul 2000 10:42:17 +0200, Serge Paccalin
<[EMAIL PROTECTED]> wrote, in part:
>On/Le Mon, 31 Jul 2000 03:52:27 GMT, [EMAIL PROTECTED] wrote/a
>écrit
>in/dans sci.crypt...
>> Back when Walter Mathau passed away, I was half listening to an obit
>> while driving home from work. As usually happens, out of the "corner of
>> my ear" I could have sworn I heard them say that Mathau was a
>> cryptographer duing WWII and won an medal or commendation or something.
>> I never heard anything else about it in any other obit and haven't found
>> any info concerning this on the web.
>They might have been talking about Hedi Lamarr:
>http://web.mit.edu/invent/www/inventorsI-Q/lamarr.html
According to the Yahoo obituary, Walter Matthau was a radioman and
gunner on bombers during World War II; as a radioman, even if he never
was a cryptanalyst during the war, it is quite likely he did operate
cipher machines to send and recieve messages, which would indeed make
him a cryptographer, even if not in the sense of a cipher inventor or
anything technical like that.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
Date: Mon, 31 Jul 2000 09:33:47 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: unbreakable code?
Graham Orme wrote:
> My apologies if this is old, but this seems to be a technique that creates
> an encryption that cannot be decoded. This is because there is a key for
> every permutation of the encrypted message, so one can make it into anything
> at all.
> This example works on 1000 digit blocks of numbers, which might be for
> example ascii. John and Mary wish to exchange messages. First, John sends by
> some secure method a (for example) 10,000 digit number perhaps by meeting or
> by courier. Mary now has the 10,000 digit number, called A. John then
> composes a password of 10,000 digits called B and subtracts A from it and
> send this to Mary. Mary receives B-A and because she knows A now knows B but
> no eavesdropper can know B or A which can be any possible 10,000 digit
> numbers. Mary gets another 10,000 digit number called C perhaps randomly and
> subtracts B from it, and sends C-B to John. Of course an eavesdropper cannot
> know C or B from the number sent. They continue in this way until they have
> enough secure passwords. Note that if someone learned A they could find out
> the rest, so the security hinges on A being secure.
> John and Mary now want to send 1000 digit numbers to each other, which
> might be ascii messages or anything else. John's first message is called Z.
> John takes the first 1000 digits of B and subtracts it from the message Z,
> then takes the next 1000 digits of B and add it to Z, then the next 1000
> digits and subtracts it from Z and so on until the 10,000 digits of B are
> used. John sends this message and Mary decodes it since she knows B. Mary
> composes a message Y and encodes it with the password C as before which John
> knows how to decode. They can continue like this forever wthout any
> eavesdropper being able to decipher any message, since each possible 1000
> digit number can be gotten from a corresponding 10,000 digit number. One
> therefore cannot narrow down what the 1000 digit message to any less than
> all the possible numbers up to 1000 digits long. The password could be less
> than 10,000 digits and still be secure, and might even be ok at 1,000
> digits.
> Any flaws in this?
Yes. When the first thousand digits, or a block of digits derived from the
first thousand digits, is used the second time it's security drops to near
zero. The same thing happens if/when the plaintext of a message becomes known
to the opponent.
Look for references describing the One Time Pad (OTP), and cases where it failed
(Venona project). OTP is the name given to systems that provide the security
you are trying to manufacture. Note the extremely heavy emphasis on ONE TIME.
------------------------------
Date: Mon, 31 Jul 2000 09:47:42 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Encrypt string to produce a unique number
yankee wrote:
> Is there any algorithm to produce a unqiue number based on a string . The
> string is except to have a maximum length of 30(the string is alphanumeric
> only) After "encryption" . It should result in a number length of not more
> than unsigned long which is about 10 .
There are many methods that will produce results where duplicates (collisions)
are rare, but there are none that will produce results that are unique. Your
input space is far too large to uniquely encode in a convenient integer.
Thus you need to refine your goals a bit.
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: BUGS v3.3.0 - CONTEST
Date: Mon, 31 Jul 2000 13:48:15 GMT
> The contest as it is is basically here is my algorithm and
> a ciphertext. This really doesn't tell if your algorithm is secure.
> To be secure, it must be secure against chosen-adaptive
> plaintext attack. A cipher-text only attack isn't really
> practical for most ciphers (even bad ones).
Good point.
What about if I give more information for this contest such as:
- 2 textfiles crypted with the same password
- The size of the key
- The language used in the text file
I think this would be more a "real world" test.
> That said BUGS appears to be more of an application than
> just a cipher. I haven't really looked at it just the nature of
> the contest. The cipher may be useful. The contest is not.
I may change the contest then and give more clues.
BUGS is actually more of a cryptography algorithm than an application.
Te applications where supposed to be only there as example. But as many
people get back to me with applications ideas I created more and more
applications around. The time spent on the application is only a 1/10 of
the tim spent on the algorithm, and were not really challenging anyway.
Cheers,
Sylvain.
---
http://www.bcrypt.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
******************************
