Saturday, July 2, 2016

Digest for comp.lang.c++@googlegroups.com - 17 updates in 3 topics

Christian Gollwitzer <auriocus@gmx.de>: Jul 02 08:17AM +0200

Am 01.07.16 um 23:23 schrieb Chris M. Thomasson:
> Online example:
 
> http://funwithfractals.atspace.cc/ffe
 
There is a bug in the decryptor.
 
I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE
 
If I change only a single byte and decrypt
 
6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu
 
First I thought it is a flaw, but encrypting again gives a different
ciphertext.
 
Christian
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 12:25PM -0700

On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:
>> Online example:
 
>> http://funwithfractals.atspace.cc/ffe
 
> There is a bug in the decryptor.
 
I don't think there is, but lets see here.
 
> I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE
 
Okay.
 
 
> If I change only a single byte and decrypt
 
> 6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu
 
> First I thought it is a flaw,
 
This is normal. You changed a single byte in the ciphertext. It will
change a single byte in the plaintext. I will do this right now.
 
The plaintext is
___________________
Christian
___________________
 
 
the ciphertext with the default key is:
___________________
0.059597818467851275 0.069599977755982
0.060204896883700613 0.20476592051063616
 
37 57 40 E6 4B AF 31 4A 83
___________________
 
You can check this by going to the page, pasting the ciphertext in the
ciphertext box. Click decrypt, and you get your first name.
 
Now... If I change a single byte, say the last (83), to say (38), and
hit decrypt I get:
 
______________________
Christia#
______________________
 
 
Now, If it hit encrypt again, I get a ciphertext of:
______________________
0.3368721280009776 0.4406627195365929
0.2638329392146355 0.16157543875510105
 
83 96 47 12 D5 23 FF 60 37
______________________
 
 
This decrypts into
 
______________________
Christia#
______________________
 
 
 
AFAICT, there is no bug. Can you please try out the ciphertext I posted
with the default key and tell me what happens?
 
 
> but encrypting again gives a different
> ciphertext.
 
Yes. Each time you click encrypt it will give a different cipher text
because it inserts an offset location into the ciphertext. These are the
4 base 10 decimal numbers. Each time you click encrypt it randomizes
this IV.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 12:28PM -0700

On 7/2/2016 12:25 PM, Chris M. Thomasson wrote:
 
>> First I thought it is a flaw,
 
> This is normal. You changed a single byte in the ciphertext. It will
> change a single byte in the plaintext.
 
When you have the secret key, or private key in the webpage, a single
change to a byte in the ciphertext creates a single change in the
resulting plaintext. This is normal.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 12:47PM -0700

On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:
 
>> http://funwithfractals.atspace.cc/ffe
 
> There is a bug in the decryptor.
 
> I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE
I am sorry, did you use the hexbyte ciphertext for another plaintext?
 
I get garbage when I map these bytes to ascii table:
 
m2[blah]
 
Or, are these hexbytes derived from the ciphertext of a plaintext you
encrypted on the page? I am wondering because there are no axes, the 4
decimal numbers. I cannot decrypt this because I need those darn axes.
Christian Gollwitzer <auriocus@gmx.de>: Jul 02 10:41PM +0200

Am 02.07.16 um 21:28 schrieb Chris M. Thomasson:
 
> When you have the secret key, or private key in the webpage, a single
> change to a byte in the ciphertext creates a single change in the
> resulting plaintext. This is normal.
 
If it's not a bug, then I think it is a flaw. I didn't bother to read
through your algorithm description, and my knowledge of encryption is
shallow - but I know that in modern algorithms, each bit of the output
is dependent on each bit of the input and the key. I think otherwise it
makes it vulnerable to known plaintext attacks. Or is each byte a block
in your block cipher (for demonstration purposes?)
 
However I do not understand how the website works. If I hit encrypt
multiple times, I get different answers with different public keys, yet
the same private key. Is this intended? I would have expected that there
is a "Generate key" button, and a button "encrypt" and another one
"decrypt" so that I can encrypt different texts with the same key over
and over again.
 
Christian
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 02:18PM -0700

On 7/2/2016 1:41 PM, Christian Gollwitzer wrote:
> is dependent on each bit of the input and the key. I think otherwise it
> makes it vulnerable to known plaintext attacks. Or is each byte a block
> in your block cipher (for demonstration purposes?)
 
Each byte is a block. It transforms each byte in the plaintext to a
point in the complex plane.
 
 
 
> However I do not understand how the website works. If I hit encrypt
> multiple times, I get different answers with different public keys, yet
> the same private key. Is this intended?
 
Yes! Also, my terminology wrt private/public key is flawed. The private
key should be secret key, and public key should be the random IV sent
along with the ciphertext. I used the word pubic because it gets sent
out for an attacker to see.
 
 
> is a "Generate key" button, and a button "encrypt" and another one
> "decrypt" so that I can encrypt different texts with the same key over
> and over again.
 
You can generate different ciphertexts with the same key. Just keep
hitting the encrypt button, and see how the ciphertext changes. If you
change a single byte in the plaintext, all of the ciphertext bytes
change. This is a fairly decent avalanche effect. However, if you change
a single byte in the ciphertext, a single change will occur in the
decrypted plaintext. This is normal.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 02:37PM -0700

On 7/1/2016 2:23 PM, Chris M. Thomasson wrote:
> [...]
 
> I am thinking on how to crack this thing. So far, using the following
> arbitrary precision library:
[...]
 
There is a flaw, Peter Fairbrother noticed it... The problem is the sign
of the real part is the first bit of a real byte in the damn plaintext!
This is crap: Total garbage. However, how can we hide a single complex
number, with around 90 points of precision? Can we just multiply it by a
complex with irrationals 90 points deep for real and imaginary parts,
try to get it back, and add more bits until we can? Can we just expand
the secret key space from a single (c), to multiple (c) and an offset to
hide this point? I think we can also add an randomized IV to the
ciphertext, along with encrypting random bytes. Also, we can use forward
iteration (c) using each byte of the plaintext as a pixel, to hide the
final point of reverse iteration. I am thinking of a hybrid of all the
above.
 
If we have a single point, it should be easy to hide? However, a block
cipher would give up much more information about the hiding process. I
think a single point is "more secure" if we cleverly hide its digits.
 
A clever combination of my existing forward iteration with Juaquin's
reverse iteration will produce a single point with many digits and a
random IV as the ciphertext that will not give any clear insight of the
first bit of the plaintext.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 03:00PM -0700

On 7/2/2016 2:37 PM, Chris M. Thomasson wrote:
 
> There is a flaw, Peter Fairbrother noticed it... The problem is the sign
> of the real part is the first bit of a real byte in the damn plaintext!
> This is crap: Total garbage.
 
I mean, the sign of the real part of the single arbitrary precision
complex number in the _ciphertext_ will be a byte in the plaintext. So,
we need to hide this single point. Block cypher makes it more difficult.
 
Any clever ideas? Suggestions?
 
Thank you all.
 
 
 
 
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 02 03:36PM -0700

On 7/2/2016 2:18 PM, Chris M. Thomasson wrote:
> On 7/2/2016 1:41 PM, Christian Gollwitzer wrote:
[...]
>> I would have expected that there
>> is a "Generate key" button,
 
That's an interesting question in and of it self. How can we generate
these secret keys? I think we can use existing fractal explorer
programs, or something simple like the one I made here, just click on a
point-of-interest to zoom in:
 
http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html
(a crude webgl experiment I made)
 
 
Its very crude, but all clickable points are valid (c)'s, this is only
in 32 bit precision, however I can do this with arbitrary precision for
very complex and sensitive values of (c). Zooming in just means that the
clickable surface area of (c) will have more digits of precision to
target the zoom just right. So, one can click in many times, and get to
a place, then click on a "capture secret key" button or something. Bang!
They have one.
 
Hummm... I need to think a lot more on this. Any thoughts on using
fractal explorers to generate secret keys?
 
Thanks again.
Mark <ma740988@gmail.com>: Jul 01 08:33PM -0700

Consider
 
# include <iostream>
# include <string>
 
 
template < typename UnsignedType,
unsigned Width = 0 >
struct Test {
 
typedef UnsignedType ValueType;
ValueType mLocalVar;
unsigned int const mAddrLocation ;
 
Test ( unsigned int const addrLocation )
: mLocalVar ( 0 )
, mAddrLocation ( addrLocation )
{}
 
Test & operator= ( ValueType val )
{
//stuff
return ( *this );
}
};
typedef Test < volatile unsigned int, 32 > TestINT ;
 
int main()
{
unsigned int argument = 15 ;
unsigned int value = 5 ;
TestINT( 5 ) = value ;
TestINT ( argument ) = value ; //FAILS
return EXIT_SUCCESS ;
}
 
 
The line marked FAILS generate errors
 
error: conflicting declaration 'TestINT argument'
error: 'argument' has a previous declaration as 'unsigned int argument'
unsigned int argument = 15 ;
 
Unclear why. Thoughts?
Paavo Helde <myfirstname@osa.pri.ee>: Jul 02 10:35AM +0300

On 2.07.2016 6:33, Mark wrote:>
> }
> };
> typedef Test < volatile unsigned int, 32 > TestINT ;
 
Side note: volatile is generally not useful for anything nowadays
(unless you deal with hardware registers).
 
> TestINT( 5 ) = value ;
> TestINT ( argument ) = value ; //FAILS
> return EXIT_SUCCESS ;
 
Side note: EXIT_SUCCESS requires #include <stdlib.h>
 
> error: 'argument' has a previous declaration as 'unsigned int argument'
> unsigned int argument = 15 ;
 
> Unclear why. Thoughts?
 
C (and thus also C++) syntax allows parens around the variable names in
the declarations, so the line is actually equivalent to:
 
TestINT argument = value ;
 
To disambiguate it, one can change the lvalue name 'argument' to a
rvalue expression:
 
TestINT ( +argument ) = value ;
 
Cheers
Paavo
Mark <ma740988@gmail.com>: Jul 02 07:51AM -0700

On Saturday, July 2, 2016 at 3:35:56 AM UTC-4, Paavo Helde wrote:
> TestINT ( +argument ) = value ;
Don't recall seeing this before. Thanks
 
I have a follow up question. I'm trying to initialize the static vector within the class. But I'm getting the error:
 
error: default argument for template parameter for class enclosing 'Test<UnsignedType, Width>::addrValueVec'
ADDR_VALUE_VEC Test < UnsignedType, Width >::addrValueVec ;
 
The code:
template < typename UnsignedType,
unsigned Width = 0 >
struct Test {
 
typedef UnsignedType ValueType;
ValueType mLocalVar;
unsigned int const mAddrLocation ;
 
typedef std::vector < std::pair < unsigned int, unsigned int > > ADDR_VALUE_VEC ;
static ADDR_VALUE_VEC addrValueVec ;
 
Test ( unsigned int const addrLocation )
: mLocalVar ( 0 )
, mAddrLocation ( addrLocation )
{}
 
Test & operator= ( ValueType val )
{
//stuff
return ( *this );
}
 
};
typedef Test < volatile unsigned int, 32 > TestINT ;
 
template < typename UnsignedType, unsigned Width = 0 >
ADDR_VALUE_VEC Test < UnsignedType, Width >::addrValueVec ;
Paavo Helde <myfirstname@osa.pri.ee>: Jul 02 08:19PM +0300

On 2.07.2016 17:51, Mark wrote:
> On Saturday, July 2, 2016 at 3:35:56 AM UTC-4, Paavo Helde wrote:
>> TestINT ( +argument ) = value ;
> Don't recall seeing this before.
 
This is because you are writing weird code (creating an unused temporary).
 
> typedef Test < volatile unsigned int, 32 > TestINT ;
 
> template < typename UnsignedType, unsigned Width = 0 >
> ADDR_VALUE_VEC Test < UnsignedType, Width >::addrValueVec ;
 
Read the error message, it is complaining about the second '= 0' which
is not needed (and probably not allowed even though MSVC seems to eat it).
 
There are other problems with this line. Welcome to the wonderful C++
template metalanguage! The correct syntax should be:
 
template < typename UnsignedType, unsigned Width>
typename Test<UnsignedType,Width>::ADDR_VALUE_VEC
Test < UnsignedType, Width >::addrValueVec;
 
What makes it so complicated is that ADDR_VALUE_VEC is defined inside a
class template Test even though it does not depend on template
parameters in any way.
 
HTH
Paavo
Mark <ma740988@gmail.com>: Jul 01 08:44PM -0700

I'm perusing MIRSA guidelines for an embedded project and 18-4-1 imposes a requirement that forbids dynamic allocation. Specifically, 'Dynamic heap memory allocation shall not be used.'
 
The factory pattern is suitable for one aspect of my code but the factory design is predicated upon dynamic allocation - at least my experience. Can I use factory design with static allocation? Did a search and I think the answer is no but thought I check in the forum
 
 
 
Link:
 
http://www.ldra.com/attachments/article/74/MISRA-CPP_2008_COMPLIANCE.pdf?reg=short
"Chris M. Thomasson" <invalid@invalid.invalid>: Jul 01 09:59PM -0700

On 7/1/2016 8:44 PM, Mark wrote:
 
> The factory pattern is suitable for one aspect of my code but the factory design is predicated upon dynamic allocation - at least my experience. Can I use factory design with static allocation? Did a search and I think the answer is no but thought I check in the forum
 
> Link:
 
> http://www.ldra.com/attachments/article/74/MISRA-CPP_2008_COMPLIANCE.pdf?reg=short
 
This just might be of no use, but it gets around dynamic allocation!
 
;^)
 
 
https://groups.google.com/d/msg/comp.lang.C++/7oaJFWKVCTw/sSWYU9BUS_QJ
 
https://groups.google.com/forum/#!original/comp.lang.C++/7oaJFWKVCTw/sSWYU9BUS_QJ
 
http://pastebin.com/f37a23918
(the code/hack)
 
 
I have used it in environments that did not support dynamic allocations.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jul 02 10:29AM +0200

On 02.07.16 05.44, Mark wrote:
> The factory pattern is suitable for one aspect of my code but the factory design is predicated upon dynamic allocation - at least my experience. Can I use factory design with static allocation?
 
Yes.
 
The storage for the target need to be provided by the caller and the
factory can use placement new to do its job. You might also use this
with polymorphism as long as the target storage is large enough to keep
any variant.
 
 
Marcel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 02 06:13PM +0100

On 02/07/2016 04:44, Mark wrote:
 
> Link:
 
> http://www.ldra.com/attachments/article/74/MISRA-CPP_2008_COMPLIANCE.pdf?reg=short
 
The factory pattern does not require dynamic freestore-based allocation;
you can reserve space for all supported concrete objects that the
factory creates.
 
As far as C++ is concerned and at its most basic level all the factory
pattern is is the calling of virtual functions.
 
/Flibble
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)