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
(Continue reading)

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
Tony Arcieri | 19 Aug 06:29 2014
Picon

STARTTLS for HTTP

Anyone know why this hasn't gained adoption?


I've been watching various efforts at widespread opportunistic encryption, like TCPINC and STARTTLS in SMTP. It's made me wonder why it isn't used for HTTP.

Opportunistic encryption could be completely transparent. We don't need any external facing UI changes for users (although perhaps plaintext HTTP on port 80 could show a broken lock). Instead, if the server and client mutually support it, TLS with an unauthenticated key exchange is used.

It seems most modern web browsers and web servers are built with TLS support. Why not always flip it on if it's available on both sides, even if it's trivially MitMed?

--
Tony Arcieri
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Tom Ritter | 18 Aug 15:58 2014

JackPair Voice Encryption Dongle

https://www.kickstarter.com/projects/620001568/jackpair-safeguard-your-phone-conversation
https://www.youtube.com/watch?v=rh6yF79FkAA

DH with a 'Pairing Code' (ala ZRTP) to prevent MITM. Light on exact
details, but they say it will be open source.

"we think 10-12 digits [for a pairing code] is probably good enough,
and more friendly for human reading"

"We are using Diffie-Hellman at this point, and working on Elliptic
curve Diffie-Hellman."

"Synchronous stream cipher is used, with XOR'ed key-stream resulted
from pseudo random number generator using OTSK as seed, and periodic
marker flag for re-synchronization."

"JackPair uses audio codec from Codec2, which has reasonable good
sound quality at 1.2kbps. We have tested JackPair on top of GSM AMR
4.75 (Adaptive Multi-Rate, 4.75kbps) and HR (Half-Rate, 6.5kbps)."

"Unlike traditional fax-modem technologies, our modem is designed from
scratch to fight off the optimization done by GSM codec, including
memory-less codec, voice activity detection (VAD)., automatic gain
control (AGC) etc.. Basically we have to use synthesized voice to make
mobile phones & media servers believe our signal is human voice, not
just modulated waves."

-tom
shawn wilson | 17 Aug 23:51 2014
Picon

Fwd: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20

Is anyone (or know anyone) in the DC area who would like to talk at
this event? The focus is on defensive security, identity, and tools
(and some UX as it relates to things like gnupg). But I'd also like to
see some more technical talks involving math or programatic use of
encryption.

If anyone is interested, the hacdc forum is an open Google group or
you can email me (I can also provide another email that I use gpg with
if you'd prefer).

---------- Forwarded message ----------
From: shawn wilson <ag4ve.us@...>
Date: Sun, Jun 8, 2014 at 7:27 PM
Subject: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20
To: "blabber@..." <blabber@...>

tldr:
Speaking/links/software spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing
Meetup event: http://www.meetup.com/hac-dc/events/187948232/

For those who don't follow the list, the back story on the subtitle
(besides me thinking it's ironic) is:
https://groups.google.com/a/hacdc.org/forum/#!topic/Blabber/-N8UxXMvfxU

First, we need speakers!!! In order to have an event like the last two
years, people need to volunteer to present on what they know. Here's
last year's doc (for reference)
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdHVlN3ZDMmNQTVlUZVJDZTA4UHZSY2c&usp=sharing
and here's this year's doc (for you to sign up and update
software/links on [1]):
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing

If you work at a news agency or activist group where you feel you're
handling communication and individuals' privacy correctly maybe you or
your CTO would like to talk about it?
If you enjoy crypto and would like to talk about your experience, sign up.
If you think that crypto is hard and have ideas on how to improve it
(I know you do) maybe you should give a talk. [2]
If you have a friends, colleges, college professors, etc who is kinda
local who you think would add content to our discussion, get them to
sign up to give a talk.

On the other hand, if you'd like to become more familiar with the most
cryptographically secure ways to store and transmit data including how
to setup encrypted (or signed) email, FDE [3], best password hashes to
use and how hashing works, common mistakes when creating
passwords/making more secure passwords, etc - please come.

Here's the meetup event: http://www.meetup.com/hac-dc/events/187948232/
The event can still be pretty flexible (there's more going on at the
church the week before, but I think we could work around that). I
think I'll wait a few days to see if anyone shows any event conflicts
(within the same sphere of computer/internet/security) but this should
be it.

[1] We can debate on the usefulness of an unmaintained TrueCrypt, but
it probably should stay in that list for now.
[2] https://researchspace.auckland.ac.nz/bitstream/handle/2292/2310/02whole.pdf?sequence=2
and later https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
[3] FDE - full disk encryption (will probably be mentioned later in this thread)
travis+ml | 14 Aug 20:12 2014

anyone do ZKS for finsys?

Anyone know of any sort of ZKS or homomorphic encryption processing
for finsys?

Apart from IFC, where might I read about that?
--

-- 
http://www.subspacefield.org/~travis/
I'm feeling a little uncertain about this random generator of numbers.

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
John Young | 11 Aug 22:52 2014
Picon

A post-spy world

"We are moving toward a post-spy world, according to the guy that runs the CIA
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography

Gmane