Cryptography-Digest Digest #928, Volume #13 Sat, 17 Mar 01 18:13:01 EST
Contents:
Password Generator Idea (Moe Harley)
Re: Password Generator Idea ("Tom St Denis")
Idea (br)
Re: Cesar principle (br)
Re: Password Generator Idea (Ross Younger)
Re: Super strong crypto (Bryan Olson)
Re: Cesar principle ("John A. Malley")
Defenses Against Compromising Emanations of the Private Key (Frank Gerlach)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Moe Harley)
Subject: Password Generator Idea
Date: Sat, 17 Mar 2001 20:17:34 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
If this is not an original idea or it has been posted before
then please forgive me.
I am looking for some input on this idea for a random
password generator. Its based on a pseudo random
number generator.
If I generate several hundred random passwords, then
xor them all together to create one password, is that
password harder or easier to guess than the previous
passwords?
Lets say for example we generate 500 passwords,
each of them 10 characters long. We systematically
begin xor'ing these all together and eventually come
up with one 10 character password. How secure is
this new password?
Would it make things tougher for an attacker if the
number of passwords we generate is also based on
the PRNG? Or would it be more secure if I just set
a large number of passwords and ran with that?
If the number of passwords we generate were
based on a different PRNG would that help?
I was thinking that I could take the number of
milliseconds between mouseclicks MOD 1000 to
come up with the number of passwords to generate.
(which of course would limit it to an application with
a gui, i'd have to get random data somewhere
else if I ran this program from a command line)
Input is much appreciated.
- -Moe Harley
[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOrPF8ReV4wgdUpL5EQIzzQCgmd+cpeyoJEQcZLGydfSQhSGq70wAni8Q
C+DRoTIBw/E2DJGSeE/aETSu
=W5N3
=====END PGP SIGNATURE=====
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Password Generator Idea
Date: Sat, 17 Mar 2001 21:02:56 GMT
"Moe Harley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
Don't sign posts.
> If this is not an original idea or it has been posted before
> then please forgive me.
Um nothing new.
> I am looking for some input on this idea for a random
> password generator. Its based on a pseudo random
> number generator.
A secure PRNG I hope... something like a LFSR, LFG or LCG are not strictly
the best things to use.
> If I generate several hundred random passwords, then
> xor them all together to create one password, is that
> password harder or easier to guess than the previous
> passwords?
Thats the same as using a LFSR and xoring bits together to make a super bit.
Similar to hardware devices and xoring bits. Used to remove biases. You
can use a Von Neuman rejector for that too. And no if your PRNG is any good
xoring 500 bits to form a single super bit is not likely.
> I was thinking that I could take the number of
> milliseconds between mouseclicks MOD 1000 to
> come up with the number of passwords to generate.
> (which of course would limit it to an application with
> a gui, i'd have to get random data somewhere
> else if I ran this program from a command line)
Note that using diff clock based inputs (the mouse has it's own clock, the
UART has a clock, the cpu has a clock, the pci bus has a clock, etc) is only
effective if there is clock drift between them (like flipping a bit waiting
for a msec to pass, this relies on the clock drift from the cpu's clock and
the computers PIC).
Tom
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Idea
Date: Sat, 17 Mar 2001 16:09:35 -0400
I'm going to explain clearly my idea.
I have two cases using cesar combined with "two types".
First case :
Bob want to send to Alice a plain-text M=hello!
I choosed a short string and cesar encryption to be more clear.
Bob choose the key k1=13, k2 = 4522858898750086534289857041282523492707
and odd and even to distinguish between bits : 0 and 1.
Bob using symetric key transmited before sending M , via a secure
channel, those keys.
Alice knows K1= 13, k2 = 4522858898750086534289857041282523492707 and
odd for 0 even for 1.
Let write E.
Encryption algo
Step 1.
Conversion of M to E' (E' is a conversion using Cesar encryption)
k1 = 13
h = u ; e = r ; l = y ; l = y ; o = b
So "hello" = "uryyb".
Step 2.
Conversion of "uryyb" to hexadecimal.
"uryyb"= 7572797962
Step 3.
Conversion of hex string to binary system
7572797962 = 0111 0101 0111 0001 0111 1001 0111 1001 0110 0010
Step 4.
I choose randomly (pseudo) odd and even number between 0 and 9.
Conversion of binary string to odd and even
Bin = 0111 0101 0111 0001 0111 1001 0111 1001 0110 0010
E'' = 4351 8705 6593 6403 6357 3205 8739 7201 6170 4012
Step 5.
I use the "principle " cesar encryption. The cesar is applied to 26
letters.
E= E" + k2
E = 4351870565936403635732058739720161704012 +
4522858898750086534289857041282523492707 =
8884629464686490270021915781002685196719
E = 8884629464686490270021915781002685196719
Step 6.
Bob compress E with any compress algo and send it to Alice.
Decryption
Alice receive E.
Alice decompress E.
Alice compute E - k2.
Alice using the two types convert odd digit to 1 and even digit to 1.
Alice convert binary to hexadecimal.
Alice disclose the message "uryyb"
Alice apply k1= 13 to "uryyb" to find the message "hello".
Using substitution of odd digit for the bit 1 and even digit for the bit
0 is not stenography.
It's like sending a code with 1 = {1,3,5,7,9} and 0 = {0,2,4,6,8}
Second case :
So, in the first case, Bob transmitted the two types to Alice (odd and
even).
In the second case which is the case I'm talking about Bob do not
transmit a code
with 1 = {1,3,5,7,9} and 0 = {0,2,4,6,8}.
Bob send a message substituing 1 to type 1 and 0 type 2 without
transmitting the code.
All the other steps are the same in the second case except
non-transmission of the code for the categories.
Alice know that the level E" ( above step 4), Bob had chosen two types.
He has to read the
message E" to guess what are the two types. Reading it is not guessing
to understand?
Anyone try to guess what other are telling. That's the same idea.
Computer could not guess.
If, without telling you that I chosen punctuation mark for 0 and letters
for letters, you can easily
make the distinction between the two types. You know that you have to
find out what categories I used.
It's not stenography. I'm not hiding. Everyone can read it. Everyone
make distinction between "a" and "o".
Everyone could distinguish vowels and consonants. So I stress. It's not
stenography. It's only coding without transmitting.
I'm using codes that everyone knows. Why to transmit them? Here some
samples.
Sample of message E" : pdr;u'.t;?td:y
Other sample using letters and numbers : prf12yg1t1uh3o3ed3ud3
I may use vowels and consonants : arodtivoveemiu....
I can give you a hundreds of samples.
It's not my goal.
So Alice has just to read with one goal : to find the coding table where
0 is represented
by a first category and 1 by the other.
If the recipient, after reading, find out which categories the sender
had used.
Alice has to use a simple algo.
1. Listing all the symbols used in a message E". It's just automatic
function which read all the string-message
removing doublons.
2. Alice has to fill every category with its matching symbols, entering
data
3. Program has to convert the first category to bit 1 and the second to
bit 0
4. Program convert the message E" to E' . If M is not readable with
1-0, Alice has to switch to 0-1
5. After two attempts, Alice may read the message M without any previous
communication.
Suppose that Alice, after reading, had distinguished letters and numbers
: i.e (prf12yg1t1uh3o3ed3ud3).
She has to enter 1 = {p,r,f,y,g,t,u,h,o,e,d,}
0 = {2,1,3}
If it works. M is readable. ok
If not switch 0 = {p,r,f,y,g,t,u,h,o,e,d,}
1 = {2,1,3}
Now, what I want to know is :
Wich strategy, cryptanalysis could use to attack this pre-cipher?
Cryptanalist have no knowledge before attacking of what categories are?
I used cesar cipher just to be clear. The use of DES will make attack
more difficult.
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Cesar principle
Date: Sat, 17 Mar 2001 16:13:55 -0400
What if I disguise the level of the bits
0 equal x={x1,x2,x3,x4...xn}
1 equal y={y1,y2,y3,....yn}?
"John A. Malley" wrote:
>
> br wrote:
> >
> > Why not? Even if people have worked in this area professionally for
> > decades.
> > I know that other people are not idiots. But new ideas, everyone may
> > try.
> > All inventions when disclosed, professionnal people say " Schit! we did
> > not thought it!!!"
> > As newbie, I'm just trying to understand.
> > I read some articles about "plain text", cryptanalist etc...
> > How cryptanalist know that for any key k' that the deciphered text (
> > using DES i.e, not RSA)is english or spanish etc...?
> >
>
> The answers to your questions are out in the open, in the references
> supplied in the sci.crypt FAQ, in books recommended to you.
>
> Cryptography is thousands of years old; cryptanalysis is slightly
> younger :-) See Kahn's book for the most comprehensive history of
> cryptography.
>
> Written and spoken languages sport patterns. Some patterns appear more
> often than others. The kinds and frequencies of patterns appearing in
> the plaintext depend on the language. These are statistical and
> structural properties.
>
> For example, on the character (alphabet) level, certain symbols appear
> more often than others in the plaintext (frequency of occurrence.)
> Certain vowels almost always follow certain consonants, certain symbols
> appear in pairs more often than other, certain symbols follow other
> symbols more often than others. This can be quantified with contact
> frequencies, digraph frequencies, trigraph frequencies, etc.
>
> On the sentence level some languages hold to a strict subject - verb -
> object pattern while other languages may be more flexible and allow
> subject - verb - object or object - verb - subject or subject - object -
> verb. This is the language's syntax.
>
> On the "meaning" level, or context of the message, certain concepts and
> thus words appear and others do not. In military traffic expect
> coordinates, military unit designations, situation descriptions,
> town/city/geographic feature names, officer names, etc. in the
> plaintext. In business traffic expect financial terms, monetary
> figures, corporate officer names, corporation names, town/city names,
> etc. in the plaintext. In personnel traffic expect family names, friend
> names, political discussion, food discussions, travel plans, terms
> related to shared hobbies, etc. in the plaintext.
>
> (Keep in mind high-level programming languages emulate human languages
> with grammars and syntax. The binaries produced at compilation
> themselves manifest encoded representations of the statistics and
> syntactic structure of the programming language. Therefore the
> statistics and structure of a binary can be used to identify what the
> binary does/is. )
>
> Ciphers (try to) produce ciphertext to disguise the statistics and
> structure of the plaintext. Cryptanalyists (try to) detect the slightest
> hint of the statistics and structure of the plaintext leaked into the
> ciphertext and leverage this information to crack the cipher.
> Cryptanalyists relate the statistics and structure of the ciphertext to
> the statistics and structure of the plaintext using knowledge of the
> cipher algorithm.
>
> A Caesar substitution algorithm, for example, preserves the syntactic
> structure of the plaintext in the ciphertext. It also preserves the
> frequencies of occurrence of symbols and contact frequencies of symbols
> in the plaintext in the ciphertext. In conjunction with a known message
> context, one can also look for probable words. This makes cryptanalysis
> somewhat "easy" and straightforward.
>
> Statistics and syntax for most Indo-European languages (like English,
> French, Italian, Russian ) can be found in many books on cryptanalysis
> (and also on the www.) Statistics and syntax for binaries, images, etc.
> may be built up in the same manner as for human languages.
>
> See Gaines' book on classical cipher cryptanalysis for a rapid
> introduction to the basic principles of cracking ciphers.
>
> Hope this helps,
>
> John A. Malley
> [EMAIL PROTECTED]
------------------------------
From: Ross Younger <[EMAIL PROTECTED]>
Subject: Re: Password Generator Idea
Date: 17 Mar 2001 21:27:02 +0000 (GMT)
Moe Harley <[EMAIL PROTECTED]> rearranged some electrons into article
<[EMAIL PROTECTED]> thus:
>If I generate several hundred random passwords, then
>xor them all together to create one password, is that
>password harder or easier to guess than the previous
>passwords?
Assuming your passwords are entirely unstructured bitstreams (as a
generalisation of ASCII text), the output password cannot conceivably
be stronger than a single n-character password (brute force attack).
However, your `random' generator may have interesting statistical
properties... As you propose to XOR them together, this would in turn
likely pass some properties on to the output password, which may be
of use to an attacker. (Of course, if your random generator can be
predicted or replayed, all bets are off!)
>I was thinking that I could take the number of
>milliseconds between mouseclicks MOD 1000 to
>come up with the number of passwords to generate.
I'd suggest you do something interesting to the raw data first, like pass
it through a hash function or block cipher, in order to take advantage
of the avalanche effect and minimise predictability.
Ross
--
Ross Younger news#[EMAIL PROTECTED] (if N fails, try N+1)
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Mar 2001 13:49:55 -0800
Douglas A. Gwyn wrote:
>
> Bryan Olson wrote:
> > ... The information theoretic analysis shows that ...
>
> There hasn't been a proper information-theoretic analysis.
You chopped the sentence in half. Analysis shows exactly
what I claimed it shows.
> The one that was posted was based on an unrealistic costing
> model, namely no limit on computation.
You chose to introduce the information theoretic model into
the discussion. If you can show that your scheme is secure
under a computational cost model, then by all means define
your assumptions and demonstrate your result.
> > ... Your system bloats the ciphertext, so even if cryptanalysis
> > requires more ciphertext, your mode may provide it.
>
> No, because the "bloat" is pure entropy.
That it may be, but for the attacker, the ciphertext it is
information, not equivocation. You've booked it on the
wrong side of the ledger.
> > Your paragraph above is the kind of thing I described as
> > hypothesizing a weakness and conjecturing a fix. You have
> > no reason to believe K is generally tractable, and no way to
> > show that your scheme would make the work factor intractable.
>
> Actually, I have plenty of reason. It's called experience.
If your experience shows K (the work factor to break a block
cipher) is generally tractable, please post your results
against 3DES, IDEA, Blowfish, Rijndael, Twofish, Serpent.
Absent that, I think we can assume that your experience with
the block ciphers that most cryptographers recommend is the
same as everyone else's: you are unable to break them.
The point provable security is to get a rigorous
justification, stronger than judgement, experience, and the
failure of determined attacks. Provable security without
the proof is nonsense. The only point to replacing a
hypothesis of security with a hypothesis of an undiscovered
proof of security, is the that the later motivates us to
work on finding that proof.
--Bryan
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Cesar principle
Date: Sat, 17 Mar 2001 14:36:54 -0800
br wrote:
>
> What if I disguise the level of the bits
> 0 equal x={x1,x2,x3,x4...xn}
> 1 equal y={y1,y2,y3,....yn}?
Now it's a homophonic substitution cipher.
There's a lot of published information on homophonic substitution
ciphers and the cryptanalysis of homophonic substitution ciphertext
available to you :-)
See Chapter 11, "Simple substitution with complexities", in Helen Fouche
Gaines "Cryptanalysis, a study of ciphers and their solution".
See Chapter 7 of "The Handbook of Applied Cryptography", available
on-line at
http://cacr.math.uwaterloo.ca/hac/
See Lessons 1, 2, 3 and 4 of the on-line Classical Cryptanalysis course
from LANAKI at
http://www.fortunecity.com/skyscraper/coding/379/lesson1.htm
A homophonic substitution cipher uses different symbols in the
ciphertext for a given symbol in the plaintext. A well-formed homophonic
substitution cipher tries to "even out" or "flatten" the frequencies of
occurrence of the ciphertext alphabet symbols in its (hopefully clever)
encoding of the plaintext symbols.
A homophonic cipher would generally substitute groups of bits and not
the individual bits 0 and 1. Groups of bits represent (encode) symbols
in the plaintext (like ASCII or opcodes in binaries.) Homophonic
substitution ciphers produce ciphertext longer than the plaintext.
A homophonic substitution cipher may leak less information on
frequencies of occurrence of symbols and contact frequencies of symbols
in the plaintext in the ciphertext compared to a simple Caesar
substitution, but nonetheless it still leaks valuable information in the
ciphertext. Digrams and trigrams in the plaintext may show up in the
ciphertext as certain strings of symbols normally following one another,
and other strings of symbols never following one another. In
conjunction with a known message context, one can still look for
probable words. Sentence structures in the plaintext appear without
change in the ciphertext (like Subject - verb - object.)
Quoting from a past post, the people in this USENET group can point you
to beginner, intermediate and advanced books and
journal articles on the subjects of cryptography and cryptanalysis
(which together make cryptology). They can answer questions on some of
the most arcane corners of mathematics relating to cryptography and
cryptanalysis.
They will expect you to put in the time reading and studying the subject
on your own. They are always willing to help answer questions as you
make your way through the subject - but it's a journey you make with
their assisting guidance - no one carries any bags for you, so to speak.
There is much to learn, it's such an interesting and exciting subject!
Check into the pointers and references :-)
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Defenses Against Compromising Emanations of the Private Key
Date: Sun, 18 Mar 2001 00:16:13 +0100
As a result of this discussion thread, I propose the following
defenses against eavesdropping on the private key:
-Cryptographic:
-Temporary Certificates: SSLv3 already supports certificate chains.
There should be a scheme to allow web site operators to derive
temporary
certificates from the certificate signed by the CA, which must of
course be supported by the applications (e.g. webbrowsers).
This allows for a dramatic reduction of the private key usage rates,
resulting in a dramatic reduction of private key signal repetition
rates.
The shannon formula can be used to establish the maxium number of
private key usage counts based on the SNR (see below).
-Electric
Design and measurement principles as outlined in NACSIM 5xxx should be
applied to cryptographic coprocessors (called "device" in the
following).
Unfortunately, many important details seem to be still classified.
FIPS 140-1 DOES NOT assure this, as it does not address compromising
emanations at all.
Using national security terminology, private keys should be considered
RED
signals, while all other signals (including session keys) need
only lesser security levels. Still, those signals need to be below
the noise floor.
Note: It is by no means sufficient to assure that private key signals
are
below the noise floor, as the private key will create emanations
whenever
it is used in an asymmetric en/decryption process. The maxmimum number
of repetitions for a given signal-to-noise ratio must be calculated
using shannon's formula.
-SNR measurements of the asymmetric encryption process: Using similar
mehods as outlined in the NACSIM 5xxx standards, the device should
be qualified for a certain maximum SNR of the private key. This SNR
is to be used for maximum private key usage counts.
Only noise derived directly from a physical source should be considered
in that measurements, which mandates a jamming device.
-no galvanic connections to the host computer: Contrary to current
commercial designs, galvanic connections (e.g. SCSI or PCI) should be
avoided, as they are very difficult to isolate from the private key
signal.
All communications to/from the device should be through fiber cables
only.
Still, the
farday cage of the device should be grounded effectively (see NACSIM
5xxx).
A dedicated ground lead for the device's faraday cage should be
provided.
Power supply should be either through a grounded battery or through a
transformer qualified for Top Secret cryptography. Obviously, the
transformer must be qualified for isolation performance in the relevant
private key frequency bands.
It seems to be a prudent measure to locate the device in a specially
(physically and electrically) secured room. The fiber connection easily
allows for that.
Especially the software approach of using temporary private
keys/certificates
seems to be promising, at least from my view as a software engineer.
Still, electrical design and qualification (measurement) is instrumental in
securing the private key.
A DEVICE OF UNKNOWN SIGNAL-TO-NOISE RATIOS HAS UNKNOWN SECURITY PROPERTIES
REGARDING THE COMPROMISING EMANATIONS THREAT.
Users should demand at least very basic emanations measurements for
cryptographic coprocessors from the vendors.
Resources:
NACSIM 5xxx standards at www.cryptome.org
"SSL and TLS" by Eric Rescorla
------------------------------
** 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
******************************
