shawn wilson | 15 Sep 11:36 2014
Picon

best practice openssl.cnf

Does anyone have a best practice options to use in use for self signed
certs with openssl?

I just noticed that default_md = md5 was in most examples and a
debian/ubuntu bug to up the default to sha1 and i think the best md
openssl supports is sha256. So I figured I'd see if anyone had made
some 'crypto best practice' openssl config file that I could go off
of?
coderman | 15 Sep 10:02 2014
Picon

RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

first and foremost:
WPA2 does NOT prevent an adversary able to inject packets at you from
downgrading crypto to flawed RC4. due to odd forgotten legacy protocol
bits, every implementation of WPA2 that i have tested is vulnerable to
an active downgrade to TKIP/RC4 while still being "WPA2" and still
showing all signs of using strongest security settings.

let me re-iterate: _WPA2 only_ as a setting on router or client device
does not prevent an active RC4 downgrade when using WPA2. AES-CCMP
must be explicitly checked for, and this is not straightforward in
end-user configuration or management utilities.

RECOMMENDATION: use a wireless packet capture utility to specifically
check for and alert on the presence of TKIP in a WPA2 session. this
never happens under legitimate circumstances. [if you know of one,
please tell me!]

TKIP in WPA2 == Active injection attack by "well funded" adversary[0]

---

i missed the renewed speculation that periodically swirls around RC4, e.g.

"I feel but cannot prove that the day is coming when we learn that
everything we ever encrypted with RC4 is very practical to decrypt"
 - https://twitter.com/marshray/status/505586082461655040

"Kind of annoyed SHA-1 is a "crypto emergency" when most of the web
was encrypted with RC4 last year and almost no one cared"
 - https://twitter.com/bascule/status/509239990216163330
(Continue reading)

John Young | 13 Sep 19:00 2014
Picon

Vulcan Cryptanalysis: Motorola Proprietary Cipher of the 1970s

http://cryptome.org/2014/09/vulcan-cryptanalysis.pdf
Vulcan: A Proprietary Cipher of the 1970s

Algorithm Description and Instant Cryptanalysis

Cornelius Jenkins Riddler

September 2014

Abstract

In the 1970s, Motorola developed a proprietary cipher known internally
as Vulcan, implemented this cipher in a custom integrated circuit, and
marketed a secure communications system based upon Vulcan under the
trade name DVP. In this paper we reveal the Vulcan cipher algorithm and
develop an eective real-time ciphertext-only cryptanalytic attack against
it. We additionally present as much historical information as we have been
able to obtain.
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Aaron Toponce | 10 Sep 22:34 2014
Picon

Complete repository of known playing card ciphers

I've since put together a site of playing card ciphers, weak and strong. It's
still _very_ much a work in progress, but some input would be appreciated:

    http://aarontoponce.org/card-ciphers/

Everything is typed up, except for Mirdek and Untitled. Currently, I'm not
including DECK, as it's not secure by modern demands, but thinking maybe I'll
create an insecure list (Mirdek might be under this insecure list, actually).

I still have a great amount of work to do, such as styling the page, adding
videos detailing the algorithms, and computer software implementations of each
of the ciphers. I'm sure there are typos and grammar errors galore. I'll
address those also, including reading flow. I probably have some facts on a few
of the implementations wrong also, that need to be cleaned up.

After the computer software implementations are created, I'll be doing more
cryptanalysis on the ciphertexts, getting more hard concrete numbers on biases,
patterns, distributions, etc.

Regardless, it's making good progress, and I would be interested on feedback,
if any, from the general crypto community. I hope this has some value, at
least. :)

I put this together, as I am interested in "field ciphers" that can be executed
by hand, and other than the one-time pad, and card ciphers, I am not aware of
any hand ciphers that are still considered "secure".

Thanks,

--

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
John Young | 3 Sep 15:46 2014
Picon

"Godfather of Anonymity" David Chaum on BBC

"Horizon: The defenders of anonymity on the internet"

http://www.bbc.com/news/technology-29032399
Paul Hoffman | 31 Aug 20:53 2014

Algorithm that can be *least* optimized on CPUs?

Greetings. I want to use "openssl speed" as a very loose proxy for "how fast is this CPU right now". (Note the
use of the word "very" there.) I also want to test systems that are running in VMs. However, if I'm comparing
across CPU families, OpenSSL might have some optimizations for some algorithms (like AES) that work
better or worse depending on the features of the CPU.

If I were to pick one algorithm that is least likely to be optimized past normal C optimization, which would
it be?

--Paul Hoffman
Aaron Toponce | 29 Aug 07:36 2014
Picon

Talon - A new hand cipher with playing cards

I've been obsessing over the past couple weeks trying to improve Bruce
Shneier's solitaire cipher, aka "Pontifex". The more I think about it, the more
I realize that there just isn't a lot that can be done about the bias without
severely slowing down the already slow algorithm. So, instead of trying to
improve on his algorithm, I came up with my own - "Talon".

This cipher discards the two jokers. You only need the standard 52-cards from a
poker or bridge set (4 suits, Ace through King). As with Pontifex, this is a
output feedback mode stream cipher. Also, when determing the value of the
output card, the same suit order is used:

    Clubs - face value + 0
    Diamonds - face value + 13
    Hearts - face value + 26
    Spades - face value + 39

An unkeyed deck would have Ace through King of Clubs, followed by Ace through
King of Diamonds, followed by Ace through King of Hearts, followed by Ace
through King of Spades.

This algorithm is executed in 4 steps. You will be making four discard piles,
or "talons", labeled 1, 2, 3, & 4 from left to right.

    1. Create four discard piles. With the deck face-up in your hand, place the
       top card in discard pile #1, the 2nd card in discard pile #2, the 3rd
       card is discard pile #3, and the 4th card in discard pile #4. For
       example, if the deck was unkeyed, then the Ace of Clubs would be in
       discard pile #1, the Two of Clubs in #2, the Three of Clubs in #3, and
       the Four of Clubs in #4.
    2. Note the face value of discard pile #1, ignoring suit, and count that
       many cards from the top of the deck, and place them on top of discard
       pile #1. If the card was a Jack, then count 11 cards from the face up
       deck in your hard, and place them on top of the Jack. Do the same for
       the other three piles, in order (#2, then #3, then #4).
    3. Collect the piles by placing discard pile #1 on top of pile #2 on top of
       pile #3 on top of pile #4, and place the stack behind the face up deck
       in your hand. If all 52 cards were in discard piles (13 cards in each
       pile), then place the newly collected stack in your hand, face up.
    4. Find the output card by looking at the face value of the top card,
       including suit. If the card is a Queen of Hearts, then the value would
       be 12 + 26 = 38. Count that many cards from the top of the deck, and
       record the face value of the next card, including suit. If the top card
       is the King of Spades (13 + 39 = 52), do not record a value, and start
       the algorithm over.

The key lies in the initial order of the deck, as with other designs. It can be
keyed with random shuffling, bridge puzzles, or passphrases. If a passphrase is
used, step 4 is replaced:

    4. Pass cut. Get the numerical value of the first character in your
       passphrase. Count that many cards from the top of the deck, and cut them
       below the rest of the cards. A = 1, B = 2, ..., Y = 25, Z = 26.

Example:

Suppose we start with the following deck order:

    TOP ..... BOTTOM
    3D,4D,KS,9S,10H,2S,4H,7S,7D,3H,9C,KD,JC,5C,QH,8H,8D,5D,6H,JD,10D,5S,7H,AS,4C,KH,2H,2C,QC,10S,QS,9H,6D,JH,5H,AC,6S,9D,JS,QD,8C,3C,6C,8S,4S,AD,KC,2D,3S,AH,7C,10C

After step 1, we would have the following 4 discard piles:

    #1  #2  #3  #4
    --------------
    3D  4D  KS  9S

After step 2, our discard piles would look like:

    #1  #2  #3  #4
    --------------
    3D  4D  KS  9S  <-- Bottom of discard piles
    10H 7S  KD  4C
    2S  7D  JC  KH
    4H  3H  5C  2H
        9C  QH  2C
            8H  QC
            8D  10S
            5D  QS
            6H  9H
            JD  6D
            10D
            5S
            7H
            AS

Remaining in my hand would be:

    JH,5H,AC,6S,9D,JS,QD,8C,3C,6C,8S,4S,AD,KC,2D,3S,AH,7C,10C

After step 3, the order of my hand would now be:

    JH,5H,AC,6S,9D,JS,QD,8C,3C,6C,8S,4S,AD,KC,2D,3S,AH,7C,10C,4H,2S,10H,3D,9C,3H,7D,7S,4D,AS,7H,5S,10D,JD,6H,5D,8D,8H,QH,5C,JC,KD,KS,6D,9H,QS,10S,QC,2C,2H,KH,4C,9S

For step 4, the Jack of Hearts is the top card. Thus, its numerical value is:

    12 + 26 = 38

Counting 38 cards gives me the Five of Clubs as my output card.

After another round, my deck would be orderd as:

    AS,7H,5S,10D,JD,6H,5D,8D,8H,QH,5C,JC,KD,KS,6D,9H,QS,10S,QC,2C,2H,KH,4C,9S,9D,JS,QD,8C,3C,6C,8S,4S,AD,KC,2D,3S,JS,AH,7C,10C,4H,2S,5S,10H,AC,3D,9C,3H,7H,7S,4D,6S

My output card would be the Four of Hearts. Thus, it's numerical value is:

    4 + 25 = 30

Talon is reversible, does not need an IV like Mirdek, and less error-prone than
Pontifex. It greatly reduces the chance of a bias, by fast mixing the internal
state through the 4 discard piles with 8 cuts in total in 1 round.

According to Bruce Schneier himself [1]:

    I see about two new cipher designs from amateur cryptographers every week.
    The odds of any of these ciphers being secure are slim. The odds of any of
    them being both secure and efficient are negligible. The odds of any of
    them being worth actual money are virtually non-existent.

The odds are stacked against me. I have looked at my algorithm, and have
determined the following holds true:

    1. The algorithm is non-linear.
    2. The algorithm is reversible.
    3. The mixing of the deck is fast, reducing the chance of a bias.

What I'm struggling with, is calculating the length of the internal PRNG. My
testing shows it is sufficient for small messages, such as the length of a
Tweet, which is practical for field operation.

Also, I don't have an implementation in a program language yet for further
analysis. This is forth coming.

I would be interested in feedback, if anyone would be so kind.

Thanks,

--

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Eric Mill | 25 Aug 18:36 2014

I made a site to test SHA-1 vs SHA-2

Feedback welcome on the site, copy, and methods:


I'm taking bug reports and requests on GitHub: https://github.com/konklone/shaaaaaaaaaaaaa/issues/

-- Eric

--
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Ryan Carboni | 21 Aug 04:30 2014
Picon

Re: Devised a Change to RC4

The biases with RC4 derived ciphers have to deal with the unlikelihood that an equivalent value (usually zero) will occur near another in the first few bytes of every 256 byte block.

Each byte is equally probable of occurring, though. By randomly permuting the bytes, and scrambling the permutation array after each block, it removes the bias. The original keystream should be sufficiently random to scramble it.

I call it a self-scrambling generator and the core concept could be paired with any stream cipher.

Might reduce the strength of some related key attacks.

I'm interested if a person can show a distinguishing attack against this.

On Wed, Aug 20, 2014 at 3:40 AM, Jeffrey Walton <noloader-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Wed, Aug 20, 2014 at 4:39 AM, Ryan Carboni <ryacko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Feed RC4 through a transposition cipher... essentially a single round
> 2048-bit block cipher.
>
> Table 1: 256 permuted bytes, serves as the PRGA
> Table 2: 256 permuted bytes, serves as the transposition cipher
> Table 3: 256 empty values, serves as the output array
> Table 4: 256 empty values, serves as the output array to rescramble the
> transposition cipher
> ...
>
> Just wondering if it's a good change.
Wouldn't you still have the same biases, but in different places?

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Aaron Toponce | 21 Aug 00:40 2014
Picon

Improving the Solitaire Cipher by Bruce Schneier

Paul Crowley at http://www.ciphergoth.org/crypto/solitaire/ identifies two core
problems with the solitair cipher:

    * The CPRNG internal state is not reversible.
    * The CPRNG output is biased.

The solitaire cipher can be found at:

    https://www.schneier.com/solitaire.html

First, I believe the irreversibility of the algorithm is due to the shift of
jokers A & B. In Bruce's algorithm, if Joker A is on the bottom of the deck,
and because the deck is circular, then Joker A occupies the same position as
the top of the deck. As such, when step 1 is executing, Joker A will end up
beneath the top card. Per his instructions:

    1. Find the A joker. Move it one card down. (That is, swap it with the card
    beneath it.) If the joker is the bottom card of the deck, move it just
    below the top card.

    2. Find the B joker. Move it two cards down. If the joker is the bottom
    card of the deck, move it just below the second card. If the joker is one
    up from the bottom card, move it just below the top card. (Basically,
    assume the deck is a loop...you get the idea.)

I think this can be addressed with the following adjustment:

    1. Find the A joker. Move it one card down. If the joker is the bottom card
    of the deck, move it to the top card.

    2. Find the B joker. Move it two cards down. If the joker is the bottom
    card of the deck, move it just below the top card. If the joker is one up
    from the bottom card, move it to the top card.

However, with my testing, I still see the same ias, even though the internal
state is now reversible. I agree with Paul's hypothesis about the probability
of the top card increasing the probability of the output card.

To reduce the bias, it seems necessary to adjust the distance between the two
jokers randomly on each round. Step 4 according to Bruce's design is:

    4. Perform a count cut. Look at the bottom card. Convert it into a number
    from 1 through 53. Count down from the top card that number. Cut after the
    card that you counted down to, leaving the bottom card on the bottom.

Instead, it could be adjusted to:

    4. Perform a count cut. Look at the bottom card. Convert it into a number
    from 1 through 53. Count down from the top card that number. Perform a cut
    on the deck after the card you counted down to, placing the cut above the
    bottom joker.

In other words, by taking the "count down cut" and placing them between the
jokers, the distance between the jokers changes randomly on each round, but it
also decreases our probability that the output card will be the same as the
previous output card, if the top card is the same after two successive rounds.

Interested in feedback, as I am sure I am overlooking something here.

Thanks,

--

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Ryan Carboni | 20 Aug 10:39 2014
Picon

Devised a Change to RC4

Feed RC4 through a transposition cipher... essentially a single round 2048-bit block cipher.

Table 1: 256 permuted bytes, serves as the PRGA
Table 2: 256 permuted bytes, serves as the transposition cipher
Table 3: 256 empty values, serves as the output array
Table 4: 256 empty values, serves as the output array to rescramble the transposition cipher

i := 0 (table 1)
j := 0 (table 1)
b := 0 (table 2)
while GeneratingOutput:
    i := i + 1
    j := (j + Table 1[i]) mod 256
    swap values of Table 1[i] and Table 1[j]
    K := Table 1[(Table 1[i] + Table 1[j]) mod 256]
    output K to Table 3[Table2[i]]
    output K to Table 4[i]
    if i = 255
        while i > 0
            swap values of Table 2[i] and Table 2[Table 4[i]]
            i := i - 1
endwhile


Just wondering if it's a good change.
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography

Gmane