Cryptography-Digest Digest #262, Volume #12 Fri, 21 Jul 00 00:13:00 EDT
Contents:
Re: testing an encryption program (Bill Unruh)
Re: Implementation of PSS-style RSA signing? (Wei Dai)
Re: how strong is my own encryption? (phil hunt)
Re: RC4-- repetition length? ("Scott Fluhrer")
Re: Idea? Need Comments... ("Big Boy Barry")
Re: New stream cipher ("Scott Fluhrer")
Re: On block cipher and automata (Terry Ritter)
Re: testing an encryption program (wtshaw)
Re: testing an encryption program (Morey Kalin)
Re: Block Cypher (Boris Kazak)
Re: An encryption protocol, version 2 ("David Thompson")
Re: RC4-- repetition length? (Bill Unruh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: testing an encryption program
Date: 21 Jul 2000 00:20:12 GMT
In <[EMAIL PROTECTED]> wes goodwin <[EMAIL PROTECTED]> writes:
]hey, don't get me wong. I doubt no one,
]but I've heard alot of talk talking about people's encryption being
]sorry.
]I would like to see some action. I was wondering if anyone can decrypt
]this text file.
]I would love to see this happen as it was encrypted with my program.
]again, don't get me wrong, I never was offended by anyone's comments. I
]am not in
]the crypto business, so my program doesn't matter at all. I made it for
]the fun of it.
]www.mindspring.com/~goodwine/text_file.txt
]This is a simple one line txt file. I would like to see someone decrypt
]it.
]thanks, and no offense meant or taken.
]wesley
Even the sorryest encryption routine cannot be decrypted with too little
information. A single letter can be encrypted with the Ceasar cypher,
about the weakest cypher in existence, and noone can break it.
So, A) Publish the details of your encryption routine.
B) publish 10MB of text encrypted with your encryption routine using the
same key. Then someone may take you up on your challenge.
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: Implementation of PSS-style RSA signing?
Date: Thu, 20 Jul 2000 17:43:34 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
> Are there any free crypto libraries out there with an implementation of
> PSS encoding for RSA signatures? PKCS#1 v2.1 refers to the technique
> as "RSASSA-PSS", and the latest IEEE P1363a draft calls the encoding
> method "EMSA3", but the two standards seem to differ slightly, for
> example, in the ordering of hash inputs. What's a good place to look
> if I want to generate standard-looking signatures of this form?
Crypto++ has included an implementation of PSSR (i.e. PSS with message
recovery) since version 2.1 which was released in 1996. I try to track
P1363a but it's not very stable yet and I don't think the
implementation in the latest Crypto++ (version 3.2) is compatible with
the latest P1363a draft.
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: how strong is my own encryption?
Date: Thu, 20 Jul 2000 23:57:28 +0100
Reply-To: [EMAIL PROTECTED]
On Thu, 20 Jul 2000 09:58:21 +0200, Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>[EMAIL PROTECTED] wrote:
>
>> - Yes, that would be interesting. I think I could get the answer from David
>> Kahn's "The Codebreakers", but where can I get it on the internet (I mean for
>> free:).
>
>Since what time are books not sold at bookstores and freely obtainable
>on the internet??
For the last part of your question, since about 1982, I'd guess.
Lots of books (and other documentation on technical subjects) are freely available
on the Internet.
--
***** Phil Hunt *****
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Thu, 20 Jul 2000 18:30:03 -0700
<[EMAIL PROTECTED]> wrote in message
news:8l80qe$bst$[EMAIL PROTECTED]...
> In article <8l32co$q9t$[EMAIL PROTECTED]>,
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> >
> > - It is now known that RC4 is efficiently distinguishable from random
> data
> > after 2Gb.
>
> How? The best I was able to do was 2^^31 calls (2^^39 values), which
> found gaps of length 3 (abca) were .00005 too likely and gaps of length
> 4 (abcda) were .00008 too unlikely.
Look at digraph statistics. Certain digraphs, such as the (00,00) digraph,
occur more frequently than expected. Other digraphs, such as the (FF,FF)
digraph, occur less frequently than expected. In addition, if the attacker
keeps track of the value of i, other digraphs come into play. For example,
the (i+1,FF) digraph is more likely than expected, and the (00,i+1) digraph
is less likely. By taking advantage of all these digraph variances (an
exhaustive list appears in the paper), it turns out that 2**30.6 outputs is
sufficient for a 90% certainty rate.
--
poncho
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Re: Idea? Need Comments...
Date: Fri, 21 Jul 2000 02:06:25 GMT
Thank you all for your comments...
"Big Boy Barry" <[EMAIL PROTECTED]> wrote in message
news:olJd5.978$[EMAIL PROTECTED]...
> H E L L O
>
> H = 8
> E = 5
> L = 12
> L = 12
> O = 15
>
> 8 + 5 = 13
> 5 + 12 = 17
> 12 + 12 = 24
> 12 + 15 = 27 = (27 - 26 = 1) = 1
> 15 + 8 = 23
>
> 13 - 17 - 24 - 27 - 23
> M Q X A W
>
>
> If a program stores a password 'HELLO' as 'MQXAW', can it be cracked in
> anyway other than a bruteforce attack using a worldlist... Am I correct to
> say that the above encryption method is one-way? And, is there a name for
> the above method... Thank you...
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Thu, 20 Jul 2000 18:52:32 -0700
<[EMAIL PROTECTED]> wrote in message news:8l6v3n$je5$[EMAIL PROTECTED]...
> AOTP-Alex One Time Pad stream cipher.
>
> Performance of this implementation is 190 Mb/sec.
> It was measured sending 256 byte in loop 777215 times.
Some random comments:
- Unless you want to be labeled as a Klewless Newbie(tm), I recommend that
you don't call it a "One Time Pad stream cipher". It's not a One Time Pad,
and at least here on this newsgroup, calling something a "One Time Pad" when
it's not is a definite sign of snake oil.
- You should be applauded by releasing your files in something other than
Word format.
- Your performance measurement "190 Mb/sec" is approximately completely
meaningless. Is this MBytes/second or MBits/second? What hardware platform
was this on? If it's 190MBytes/second on an 6 MHz IBM AT, well, I'm quite
impressed. If it's 190MBits/second running on a 2000MHz Itanium, I'm not.
One idea would be to normalize your measurements into cycles per byte
encrypted. This number isn't the be all and end all of performance
measurements, but at least it cancels out some of the variances due to CPU
clock speed
- Again, I think you'll get more exposure to your ideas if 1) you write
them out mathematically (and just saying "how we do a group operation" is
not a specification) and 2) implement them in C -- hardly anyone in the
crypto community has a Delpha implementation available.
- There's a serious problem in your Delphi code. Your Alex.NextEffkey
function updates the first 128 entries in the EffectiveKey array. Your
Alex.AOTP_encryption and Alex.AOTP_decryption routines use all 256 entries.
The result of this is that every other 128 byte block is hardly encrypted at
all -- not at all if the EffectiveKey array happens to be zero there, and
with a fixed permutation if the EffectiveKey array happens to have a nonzero
value there. In either case, that's not what you want to do.
I haven't done much serious analysis on the cipher itself -- but the above
should give you some thoughts...
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On block cipher and automata
Date: Fri, 21 Jul 2000 02:49:43 GMT
On Thu, 20 Jul 2000 09:55:42 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>A common block cipher is a function that, determined by its
>key, is a (fixed) bijective mapping between its input plaintext
>and its output ciphertext. It can thus be considered to be
>a Mealy automaton (or equivalent) with one single state.
>
>It seems to be reasonable to expect that a more general cipher,
>presumably more flexible and thus better in a position to
>acquire strength, would behave like a Mealy automaton with more
>than one state and perhaps even provided with some additional
>subtleties in its state transitions.
>
>I suppose that possibly all existing ciphers could be interpreted
>as very special instances of this general concept which, therefore,
>should be at the foundation of future crypto designs.
An alternate generalization occurs by expanding the input block size
beyond the plaintext to also include "extra data." The "extra data"
can be "state" information, which might depend upon prior cipherings.
The model thus supports conventional block ciphering as a special case
of "extra data," either as a constant, or as the key. More generally,
multiple different encryptions (homophones) of the same data can be
produced, depending upon the value of the "extra data." One way to
interpret the "extra data" might be as a sort of sub-cipher selection
value. This ability to dynamically change the cipherings for the same
data would also seem to be at the essence of a stream cipher.
But when the ciphertext has equal size to the input (including "extra
data"), the model is operating within the general context of a block
cipher, yet can now address state, homophonic, and error-detection /
authentication issues within the cipher proper. By using really
random values, different blocks can have different "extra data," and
thus we get different encodings for the exact same plaintext out of an
ordinary block cipher. By using the same RNG sequence on both ends, a
masquerading block -- or just a data error -- can be detected by
finding an incorrect "extra data" value when deciphering. Or the
"extra data" can represent a "channel number" to support multiple
real-time conversations within the same ciphering context. Various
"extra data" uses may occur simultaneously.
In practice, the use of "extra data" implies some data expansion, and
adding significant extra data to each block means we need a large
block for best efficiency. But since we always need error-detection
anyway, and now can handle error-detection as a part of the cipher,
the overhead may be less than it may at first appear.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: testing an encryption program
Date: Thu, 20 Jul 2000 20:13:53 -0600
In article <8l84vs$87s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Bill Unruh) wrote:
>
> So, A) Publish the details of your encryption routine.
> B) publish 10MB of text encrypted with your encryption routine using the
> same key. Then someone may take you up on your challenge.
If you want a little Bar-B-Que, you need not eat the whole cow. Something
less than A or B will help. For starters, and see if there is interest,
generally describe the appoach to encryptioin that you are using, and give
a describtion of the data formats involved.
--
Pat B. reminds us that he served in the Nixon Administration for
six years. How can he be proud of that?
------------------------------
From: [EMAIL PROTECTED] (Morey Kalin)
Subject: Re: testing an encryption program
Date: Fri, 21 Jul 2000 02:52:38 GMT
wes goodwin <[EMAIL PROTECTED]> wrote:
>This is a simple one line txt file. I would like to see someone decrypt
>it.
I cracked it! It says, "I didn't read the FAQ."
==============================================================
>2.3. How do I present a new encryption scheme in sci.crypt?
>
> ``I just came up with this neat method of encryption. Here's some
> ciphertext: FHDSIJOYW^&%$*#@OGBUJHKFSYUIRE. Is it strong?'' Without a
> doubt questions like this are the most annoying traffic on sci.crypt.
>
> If you have come up with an encryption scheme, providing some
> ciphertext from it is not adequate. Nobody has ever been impressed by
> random gibberish. Any new algorithm should be secure even if the
> opponent knows the full algorithm (including how any message key is
> distributed) and only the private key is kept secret. There are some
> systematic and unsystematic ways to take reasonably long ciphertexts
> and decrypt them even without prior knowledge of the algorithm, but
> this is a time-consuming and possibly fruitless exercise which most
> sci.crypt readers won't bother with.
>
> So what do you do if you have a new encryption scheme? First of all,
> find out if it's really new. Look through this FAQ for references and
> related methods. Familiarize yourself with the literature and the
> introductory textbooks.
>
> When you can appreciate how your cryptosystem fits into the world at
> large, try to break it yourself! You shouldn't waste the time of tens
> of thousands of readers asking a question which you could have easily
> answered on your own.
>
> If you really think your system is secure, and you want to get some
> reassurance from experts, you might try posting full details of your
> system, including working code and a solid theoretical explanation, to
> sci.crypt. (Keep in mind that the export of cryptography is regulated
> in some areas.)
>
> If you're lucky an expert might take some interest in what you posted.
> You can encourage this by offering cash rewards---for instance, noted
> cryptographer Ralph Merkle is offering $1000 to anyone who can break
> Snefru-4---but there are no guarantees. If you don't have enough
> experience, then most likely any experts who look at your system will
> be able to find a flaw. If this happens, it's your responsibility to
> consider the flaw and learn from it, rather than just add one more
> layer of complication and come back for another round.
>
> A different way to get your cryptosystem reviewed is to have the NSA
> look at it. A full discussion of this procedure is outside the scope
> of this FAQ.
>
> Among professionals, a common rule of thumb is that if you want to
> design a cryptosystem, you have to have experience as a cryptanalyst.
==============================================================
--
"Morey Kalin" is actually 0853 964712 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Block Cypher
Date: Fri, 21 Jul 2000 03:32:06 GMT
Martin 'SirDystic' Wolters wrote:
>
> Hi,
>
> A few weeks ago, i made a first attempt
> to write a block cypher, and I wanted to
> ask about its strength. It's a little bit more
> complex than the other 'How secure is my
> cypher'-cyphers, but I hope I can describe
> it though.
>
> First, it takes a 64-Bit key from the user.
> Then it does 16 Permutations. Each time
> it takes every 2nd Bit to form 16 subkeys
> of 32 Bit each.
>
> From each subkey it takes the first and
> the last Bit to form a 64 Bit Masking Key.
>
> After generating the subkeys, it asks the
> User to enter a string to be encrypted.
> This string is padded with zero bits, until
> its length mod 62 is 0. Every 62-Bit Block
> gets a parity Bit of its first half on the beginning
> and one of the second half on it's end.
>
> Then the encryption starts. The second half
> of the block to be processed is XORed with
> the subkey n. The block then is turned around,
> so that the most significant bit becomes the
> least significant bit, and so on. This repeats
> 16 times, so that the block is XORed with
> every subkey.
>
> The Masking Key is Left-Shifted by the number
> of the processed Block and is then XORed with
> the it.
>
> To decrypt the block, the subkeys are used in
> reverse order, and after the decryption is complete,
> the parity Bits are checked. If they're correct, the
> Plaintext is outputted.
>
> I hope my Algorithm isn't as bad as the others.
>
> Bye,
>
> Martin Wolter
========================
Do I understand it correct, that you take 64 bits of plaintext,
repeatedly XOR them with all subkeys one after another, then
XOR the result with the Masking Key(left-shifted)?
If so, then all your cipher boils down to simple XOR substitution,
where you just have one (1) KEY of 64-bit length. This KEY is
the product of XORing of all the subkeys plus Masking Key.
This cipher is broken with one (1) trial encryption of known
plaintext. Just take the ciphertext, XOR it with the known
plaintext, and get the KEY.
(Also, it is not clear, when do you left-shift the Masking Key.
If the Masking Key is shifted for subsequent blocks, then you
will need not 1 , but a sequence of 64 trial encryptions.)
Best wishes BNK
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: An encryption protocol, version 2
Date: Fri, 21 Jul 2000 03:33:24 GMT
(posted&mailed)
Dido Sevilla <[EMAIL PROTECTED]> wrote :
> Mark Wooding wrote:
...
> > by a MAC, a good choice would be HMAC-SHA1. It's slower than raw SHA1
> > by an additive constant (not a factor), and gives security which is
> > provably related to the strength of SHA.
> >
>
> Where can I find sample C code and/or specifications for this
> algorithm? I hope it's not too different from SHA-1 because I've
> already implemented that algorithm for my embedded processor.
HMAC is a construction that builds on any cryptohash, of which
SHA1 is only one example. Specifically HMAC-H is H( k' . H( k" . m ) )
where . is concatenation and k' and k" are variants of the key k
formed by padding to the compression-block size and XORing
each byte with 0x5C and 0x36 respectively. Given that you
already have SHA1 (or other H) implemented, this is only
about 6 actual lines of C code additional. You may also see
HMAC-H-t e.g. HMAC-SHA1-96; that's just truncating to t bits.
RFC 2104 is the best spec I know, and includes sample code
(using MD5, which I think at that time was still well-liked);
RFC 2202 has test vectors using SHA1 and modified sample code.
RFCs are available at www.rfc-editor.org and fine mirrors everywhere.
2104 refers to CRYPTO 96 and FOCS 96 (which I haven't checked).
HAC (Menezes et al) 9.5.2 explains attacks on the more obvious
and simpler constructions H(k.m) or H(m.k), and recommends
a construction with slightly different k' and k" than 2104.
Individual chapters of HAC are available online, basically
for personal use only, at http://www.cacr.math.uwaterloo.ca/hac/ ,
but IMO the whole book is well worth buying; your call.
AC2 (Schneier) 18.14 notes the attacks briefly and suggests
three constructions, similar but not identical to 2104.
> ... Perhaps I
> should just use my encryption algo. as my MAC, or are there problems
> with using a block cipher as a MAC.
>
The last block from chained encryption, especially CBC, is also
a popular MAC construction. If using (single) DES, the keyspace
is not really big enough now and you should superencrypt the result.
If using a (decent) 128-bit block cipher, you're fine. HAC 9.58.
If you are encrypting the data anyway, it *may* be sufficient to include
a hash with the plaintext, but there are several pitfalls. HAC 9.6.5.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4-- repetition length?
Date: 21 Jul 2000 03:53:34 GMT
In <8l8a47$dhd$[EMAIL PROTECTED]> "Scott Fluhrer" <[EMAIL PROTECTED]>
writes:
]<[EMAIL PROTECTED]> wrote in message
]news:8l80qe$bst$[EMAIL PROTECTED]...
]> In article <8l32co$q9t$[EMAIL PROTECTED]>,
]> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
]> >
]> > - It is now known that RC4 is efficiently distinguishable from random
]> data
]> > after 2Gb.
]>
]> How? The best I was able to do was 2^^31 calls (2^^39 values), which
]> found gaps of length 3 (abca) were .00005 too likely and gaps of length
]> 4 (abcda) were .00008 too unlikely.
]Look at digraph statistics. Certain digraphs, such as the (00,00) digraph,
]occur more frequently than expected. Other digraphs, such as the (FF,FF)
]digraph, occur less frequently than expected. In addition, if the attacker
]keeps track of the value of i, other digraphs come into play. For example,
]the (i+1,FF) digraph is more likely than expected, and the (00,i+1) digraph
]is less likely. By taking advantage of all these digraph variances (an
]exhaustive list appears in the paper), it turns out that 2**30.6 outputs is
]sufficient for a 90% certainty rate.
I have difficulty in understanding this. What differentiates 00 from ff.
Ie, the algorithm is symmetric under interchange of any two numbers,
since all arithmetic is modulo arithmetic ( mod ff). This may be true
for some particular key, but how could it be true of a random key?
------------------------------
** 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
******************************
