Wednesday, March 18, 2020

Digest for comp.lang.c++@googlegroups.com - 13 updates in 2 topics

Paavo Helde <myfirstname@osa.pri.ee>: Mar 18 09:31PM +0200

On 18.03.2020 19:59, Frederick Gotham wrote:
> Yesterday I started writing my own encryption program. With all this talk of so-called 'quantum' computing and the possibility that our best algorithms might become brute-forceable, I've decided to start writing something new.
 
Just curious, what makes you think you can beat the professional
cryptographers who have already worked on this exact problem for at
least a decade (and have already produced some results like elliptic
curves)?
 
> Having worked developing a Linux embedded device with a 32-Bit ARM processor, very limited hard disk space and very limited RAM, I have seen the true convenience and power of programs that are fully-functional when reading from stdin. 'tar' and 'openssl' are good examples as they don't seek on their input even when doing complex tasks.
 
> On one of the devices I'm developing, tar is used to exract a file to stdout, where openssl then decrypts it to stdout, where tar then extracts another inner file. Because of very limited hard disk space and RAM, this wouldn't be possible without the piping capabilities of tar and openssl.
 
Do you indeed believe that the additional constraint on the algorithm to
support piping will somehow make the algorithm harder to crack for a $$$
quantum computer?
 
> My encryption program will encrypt blocks of 16 bytes at a time, and the scheme will be similar to CBC, however I'll be doing something new which I haven't seen done before (at least not publicly).
 
If I understand correctly, CBC is a symmetric cipher; these are
considered quite safe against quantum computers, one just needs to
increase the key sizes. It is the public key algorithms which are under
the threat.
 
IOW, you are trying to solve a non-problem while having no
qualifications for doing that. Seems a good match to me!
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 18 01:23PM -0700

Pavo wrote:
 
> problem for at least a decade (and have
> already produced some results like
> elliptic curves)?
<snip>
> Do you indeed believe that the additional
> constraint on the algorithm to
support
> piping will somehow make the algorithm
> harder to crack for a $$$
quantum computer?
<snip>
> against quantum computers, one just needs to
> increase the key sizes. It is the public
> key algorithms which are under
the threat.
<snip>
> IOW, you are trying to solve a non-problem
> while having no qualifications for
> doing that. Seems a good match to me
 
 
I encourage independent ideas in myself and also in others. I think it's okay to compare apples and oranges, and I think it's okay to re-invent the wheel.
 
I really think it's a bad idea to discourage a person from doing something simply because somebody else did something similar, or because another person (or a group of people) put more work into a similar idea and produced something good.
 
Irrespective of what any group of people did a thousand years ago, or ten years ago, I'm writing my own encryption program.
 
In my day job I do some work on encrypted communication, for example recently I implemented the OSDP protocol in fully-portable C++98 code (even accounting for 9-bit bytes and padding bytes within integer types).
 
I think I'll do a goood job on my encryption program, and I reckon there's a small chance that people might notice. I think this because I've been reading up on encryption, looking through libraries like Crypto++, and I can't find any implementations of the ideas I've come up with. I think I have two new ideas that haven't been explored yet.
 
With regard to qualifications, and whether one person or another person is licensed to put forward their ideas on a particular topic, I really think that's a poor attitude.
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 18 01:28PM -0700

I wrote:
 
> (even accounting for 9-bit bytes and
> padding bytes within integer types).
 
 
I meant "padding bits".
 
Also allowing for BigEndian, LittleEndian, One's Complement, Sign Magnitude.
Real Troll <Real.Troll@Trolls.com>: Mar 18 04:50PM -0400

On 18/03/2020 17:59, Frederick Gotham wrote:
> <tl;dr>
 
> Does anyone have any thoughts on this?
 
Assuming you are not a troll, to get any advice or views from
experienced C++ programmers (Kuyper, Montero or Helde to name just a
few) , you need to provide snippets of your code. There is no point in
asking anything if you are not able to show us what exactly you have
done so far.
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 18 03:09PM -0700

Real Troll wrote:
 
> you need to provide snippets of your code
 
 
I'm still drawing pictures. I'll have code in a day or two.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 18 03:10PM -0700

On 3/18/2020 3:09 PM, Frederick Gotham wrote:
> Real Troll wrote:
 
>> you need to provide snippets of your code
 
> I'm still drawing pictures. I'll have code in a day or two.
 
Make sure to give the folks over on sci.crypt a chance to take a look.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 18 03:11PM -0700

On 3/18/2020 3:10 PM, Chris M. Thomasson wrote:
 
>>> you need to provide snippets of your code
 
>> I'm still drawing pictures. I'll have code in a day or two.
 
> Make sure to give the folks over on sci.crypt a chance to take a look.
 
Fwiw, I am at a point where they are telling me that my cipher is beyond
their expertise.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 18 11:43AM -0700

On Wednesday, March 18, 2020 at 12:59:44 PM UTC-4, Bonita Montero wrote:
> >> There's no limitation on my side.
 
> > ... That's a major limitation of one's ability to understand C++ code.
 
> Everyone without your crystal ball has this limitation.
 
I don't own a crystal ball. All I have is the ability to understand C++
syntax. Yet that ability is sufficient for me to understand the
following code:
 
> >   }
> > }
 
> v can be a type castable to an integer.
 
Yes it can, but that's not a requirement. It would be sufficient for it
to be comparable with 0 for equality. Pointers cannot, in general (there
are specific exceptions) be safely converted to integer types, but they
can all be compared with 0 for equality - the 0 is handled as a null
pointer constant which gets implicitly converted into a null pointer of
the pointer's type before making the comparison. A class type with a
compatible overload for operator==() would also make it work.
 
If this code has been successfully compiled by a conforming
implementation of C++ without generating any diagnostics, it's
guaranteed that the type is comparable with 0 for equality. If it hasn't
been compiled that way yet, you'll find out the first time you do try to
compile it that way. Of course, if the relevant type is a typedef or a
template parameter, you won't find out until the first time that you
compile it when that typedef or parameter describes a problematic type -
but even so, you will find out at compile time, not run time.
 
> > Noone really needs to know the type of the container, in this instance.
 
> But in most other instances.
 
I've found it quite common that I didn't need to know the exact type
that "auto" has been used for. Whenever that is the case, using auto
rather than the explicit type improves the readability. I will agree
that "auto" should not be used when that is not the case.
Sam <sam@email-scan.com>: Mar 18 01:18PM -0400

Bonita Montero writes:
 
>>> There's no limitation on my side.
 
>> ... That's a major limitation of one's ability to understand C++ code.
 
> Everyone without your crystal ball has this limitation.
 
Too bad, so sad. I guess you'll have to figure it out without having one,
then. Life's so unfair.
 
>>   }
>> }
 
> v can be a type castable to an integer.
 
Or a suitable operator== overload. Please learn a little bit of C++.
 
>> Noone really needs to know the type of the container, in this instance.
 
> But in most other instances.
 
In most other instances almost everyone can figure this out too. Just not
you.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 18 07:46PM +0100

>> I do it like everyone, but this is an unecessary effort.
 
> Not really much of an effort. You just have to know C++.
 
How much depends on the complexity of the type. And if auto is used
regulary in a project the effort sums up to a essential part of the
work.
However, no matter how complex the type is, it's just unecessary.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 18 07:48PM +0100

> I don't own a crystal ball. All I have is the ability to understand
> C++ syntax. Yet that ability is sufficient for me to understand the
> following code:
 
In this example maybe. But often it's impossible to guess the type.
 
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 18 12:37PM -0700

On Wednesday, March 18, 2020 at 2:48:20 PM UTC-4, Bonita Montero wrote:
> > C++ syntax. Yet that ability is sufficient for me to understand the
> > following code:
 
> In this example maybe. But often it's impossible to guess the type.
 
It's also often unnecessary to guess the type. If it's both necessary
and impossible with this approach, don't use this approach. But there's
nothing wrong with this approach when it's either unnecessary or trivial
to guess the type, and that is often the case.
Keep in mind that it's often not necessary to guess the exact type of
something; it's often only necessary to guess certain characteristics of
the type.
 
Ian Collins <ian-news@hotmail.com>: Mar 19 09:05AM +1300

On 19/03/2020 07:41, Sam wrote:
 
>>> Or a suitable operator== overload. Please learn a little bit of C++.
 
>> If you arguing against yourself there's nothing more to say.
 
> Here are your toys. You can go home now.
 
See what happens when you feed the troll?
 
--
Ian.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)