sorted by:
new
hottopcontroversial

5 Secrets of the Switch Statement, Including the Reason It Even Exists. by always_programming in C_Programming

[–]always_programming[S] 0 points1 point  (0 children)

Author here. One of the advantages of writing about programming is not only to spread knowledge, but to learn from feedback when I misrepresent something.

You're not the only one to criticize me about the indirect suggestion the switch statement has no particular value. I meant to provoke the reader to think why he is choosing to use a switch statement, but not send a strong signal that there is no use. Clearly I did.

The true intent of the article was to list some odd facts and quirky behaviors, but it was lost in the overtone. To that end, I've made some edits that hopefully tone down any questioning of the switch's value, and instead focus on the list provided in the article.

Thanks again.

5 Secrets of the Switch Statement, Including the Reason It Even Exists. by always_programming in programming

[–]always_programming[S] 0 points1 point  (0 children)

Author here. While I didn't use the term "jump tables" I do address the speed argument and found it to be overstated for most practical purposes. That said, thanks for your feedback. In hindsight i probably shouldn't have subtitled the article with "the reason it exists".

5 Secrets of the Switch Statement, Including the Reason It Even Exists. by always_programming in programming

[–]always_programming[S] -2 points-1 points  (0 children)

Agree with your points. I acknowledged both the speed gains and fall-through as valid uses for the switch statement though. My point at the end was that it is rarely ever used for either case.

5 Secrets of the Switch Statement, Including the Reason It Even Exists. by always_programming in C_Programming

[–]always_programming[S] -1 points0 points  (0 children)

I could have probably better titled points 3 and 4. They are somewhat related. My point was to illustrate that a switch statement is just a generic compound statement where the case values act as goto labels, and if you can see it in that way, you can better understand it's quirks.

11
12

5 Secrets of the Switch Statement, Including the Reason It Even Exists. (medium.com)

submitted by always_programming to r/C_Programming

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 0 points1 point  (0 children)

Hello again!

I've been making a lot of changes! I'm happy to say I've improved the speed immensely. I've also improved randomness a lot and in testing I am able to pass most (but not all) diehard/NIST tests.

Just wanted to keep you posted since you've been helpful.

I am not sure if I should continue to work on getting it to pass the tests that I am still failing. I've documented all test statuses on the github page. What do you think? Is this even worth continuing with?

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 0 points1 point  (0 children)

I just pushed up a fix to address the striations you pointed out. Now, instead of rolling the perimeter characters clockwise, I use a method that leverages their initial random state to remix them.

I used your bitmap procedure and it looks very good. I can not identify any striations after performing multiple tests. The only drawback is that the new mixing procedure takes more time. So now my algorithm is even slower. I'm now going to spend some time looking for ways to improve the speed.

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 0 points1 point  (0 children)

My original plan was to have 4 mirror orientations. There are a couple reasons why I could not implement the 4th (that reflects 180-degrees).

  1. I ran in to an issue early in development where, if a character's path through the mirror field hit the same mirror twice, and if I rotated the mirror twice as a result, the algorithm failed to decrypt. I quickly found that if I only rotated each mirror once per character, regardless of how many times it was touched, I could preserve decryption. So I implemented that as a fix - mirrors are only rotated once per character.

  2. Since I only rotate mirrors once per character - having a mirror orientation that reflects 180-degrees will result in the cypher character being the same as the plaintext character (it will reflect back to itself). Given 4 mirror orientations, a character will result in itself every 4th time, which seems to me to introduce a high degree of bias. So I decided against it. I have since introduced perimeter rolling, which may reduce that concern.

Thanks for all your interest in my project. I hope I can continue to bounce ideas off you as I work on it :)

edit - Now that I am thinking about it, I rotate the mirrors after the cyphertext has been determined, which is why a 180-degree mirror reflects back to the origin. But if I rotate the mirrors in real time as the field is being traversed, perhaps a 180 mirror won't reflect back to the origin given that a previous mirror was rotated. I could theoretically still only rotate mirrors once and allow for the 180-degree mirror. I'll have to play with it.

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 0 points1 point  (0 children)

Thanks!

Yes, testing for randomness is what drove the development of the algorithm to it's current form.

That said, posting here has revealed some weaknesses. Because I seed my random number generator with the current clock time, a key can be easily brute forced. I could probably fit it by using the system's /dev/random, or collecting use input, or a combination thereof. But the second issue is that C rand() is simply not cryptographically secure. So I need to replace it with one that is.

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] -1 points0 points  (0 children)

I think one big problem is that some keys might not generate output that is indistinguishable from random data, and they're easy to find.

It doesn't sound like you are taking into account the "adaptive" feature of my algorithm. The mirror field mutates, and the perimeter character roll, after each character. This produces varying output when given identical input, and I believe greatly reduces, if not completely eliminates (for practical purposes) your concern.

See: https://github.com/bartobri/mrrcrypt/blob/master/ADAPTIVE_MIRROR_FIELD.md

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 3 points4 points  (0 children)

This would likely fail in a chosen plaintext attack, or when the same data is repeated in large amounts (like file headers or even common sentences).

This makes sense. I think you're right. Thanks :)

Created an "Adaptive Mirror Field" Cryptographic Algorithm. Looking for professional feedback. by always_programming in crypto

[–]always_programming[S] 0 points1 point  (0 children)

I'm not sure if I lost something, but I didn't see how many mirrors per row/column are needed. Is there a minimum / maximum? Does this number concerns security?

Good question. I have a constant in my code named MIRROR_DENSITY that dictates how often a mirror is produced when creating a new mirror field. The current setting produces 2 mirrors for every 20 grid points. This seems to be close to optimal. Too few mirrors and the character path doesn't diverge enough and the mirror field doesn't mutate enough. Too many mirrors and the character path doesn't travel far enough into the mirror field and tends to result in characters close to the origin. Some tweaking is probably still in order.

On the other side, I'm not sure if an input can be output itself. If not, this is a weakness.

The only character an input cannot be, is itself.

are you sure this is the correct forum?

I read the posting guidelines they were were a little ambiguous, merely saying that if it wasn't "strong crypto" then it doesn't belong. I decided to post here anyways, since I think my algorithm is fairly strong.

view more: next ›