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
John Young | 28 Jul 22:30 2014
Picon

NSA Systems Abroad Query

What is NSA "WB Quad System" for GCHQ, Amberwind (PL), TIGERFIRE (IN), IBIS (AU, JP), GCSB SSO Site (NZ):

http://cryptome.org/2014/07/nsa-fy13-semiannual-report.pdf

This is an NSA travel expenses report. Via Jason Leopold.
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Picon

Weak random data XOR good enough random data = better random data?

Hey everyone,

If I XOR probably random data with good enough random data, does that result in at least good enough random data?


I'm working on some Javascript client side crypto. There's a cryptographic quality random generator present in modern browsers, but not in older ones. I also don't trust browsers' random generators' quality.

I'd like to ship a few KB (enough) of random data and XOR it with whatever the best-available RNG comes up with. That way the user can still verify that I didn't mess with the randomness, no MITM attacks can mess with the randomness, but given a good transport layer I can still supplement usually bad randomness.

I don't see how it could reduce the randomness to XOR with patterned data. If someone knows better of this, let me know. If I'm correct that also means it should be okay to reuse the few KB's should they ever run out (in this system), at worst it no longer improves the randomness. I don't expect that to ever happen, and I'd prefer requesting new KB's, but it's still interesting.

Could someone confirm this whole thought-train for me? That means, is it a good idea to (over HTTPS) send some randomness*, XOR it with the best-available RNG for better randomness? I actually feel pretty confident about it, just asking for (a few) second opinion(s).

Best regards,
Lewis

* It'd probably siphon down from a Linux OS, but ofc the code is portable so randomness is probably low quality too.
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography

Gmane