Two empty encryptions

[Roger|Dyalog]

How large can an empty array be? Answer: As large as you have the workspace for it.

      x←0⍴⊂1234567⍴'a'
      ⍴x
0
      ⎕size 'x'
1234640

The explanation is that the prototype of an array can be quite spacious. This fact can be exploited to devise an encryption whose code string is an empty vector.

      encode←{0⍴⊂(⎕AV⍳⍵)⍴¨'a'}
      decode←{⎕AV[≢¨⊃⍵]}

      p←encode 'The heart has its reasons that the reason does not know.'
      ⍴p
0
      decode p
The heart has its reasons that the reason does not know.

Simple Arrays

Can a similar manoeuver be pulled off using only simple arrays? Yes it can, albeit only for short plaintexts.

A Dyalog APL array can have rank up to 15, and each dimension can be as large as 2*53. (A dimension can actually be as large as (2*64)-2*11, but integers larger than 2*53 are not mutually distinguishable.) If one of the 15 dimensions is 0, the lengths of the other dimensions, a total of 14×53 or 742 bits, can be used to encode information. If 6 bits are used for each character, then a plaintext of length up to 123 can be encoded. Thus:

      ⍝
assert←{⍺←'assertion failure' ⋄ 0∊⍵:⍺ ⎕SIGNAL 8 ⋄ shy←0}

encodeS←{
  A←' ',⎕A,⎕D,'.,-'''
  assert 123≥n←≢⍵:
  assert ⍵∊A:
  m←⌈6×n÷53
  0⍴⍨0,2⊥⍉(m,53)⍴(53⍴0),⍨,⍉(6⍴2)⊤A⍳⍵
}
      
decodeS←{
  A←' ',⎕A,⎕D,'.,-'''           
  n←53ׯ1+≢⍴⍵
  A[2⊥⍉((⌊n÷6),6)⍴,⍉(53⍴2)⊤1↓⍴⍵]
}

      q←encodeS 'THE HEART HAS ITS REASONS THAT THE REASON DOES NOT KNOW.'
      ⍴q
0 2.83251E15 8.81837E12 6.36079E14 4.6447E15 1.17006E15 1.49095E15 2.16291E15

      decodeS q
THE HEART HAS ITS REASONS THAT THE REASON DOES NOT KNOW.

It is amusing that displaying q engenders a WS FULL, even though q is empty. This is probably a bug.

      q
WS FULL
      q
      ∧

[Bob Armstrong]

Roger , your examples raised the question of whether non-empty emptys were possible in CoSy's simple lists of lists 3 item header | `( type count refCount )` | . Adding a type anything's possible , however bad an idea .

The only types now are

Code: Select all

 `( sys Types )` Dv@ fmttbl
(
 Type0   0   
 TypeC   1   
 TypeI   4   
 TypeFl  10 
 )

And the type is also the item bytes , except for general Type0 which is list of pointers ( to lists ) .

The equivalent to
x←0⍴⊂1234567⍴'a'
is

Code: Select all

  ` a 1234567 _take 0 _take   dup DMP   >t0> cr DMP

   | /\ | sF6  to execute in raw Forth then   F5 to insert .
001966A0 01 00 00 00  00 00 00 00  00 00 08  00 00 00 00 00 ................
001966B0 00 00 00 00  00 00 00 00  63 14 3E  ED 8E 25 00 10 ........c.>..%..

001966A0 01 00 00 00  00 00 00 00  01 00 08 00  00 00 00 00 ................
001966B0 00 00 00 00  00 00 00 00  63 14 3E ED  8E 25 00 10 ........c.>..%..


The first Dump before and the second after the assignment to ' t0 .
Note the only difference is the increment in refCount

( The second lines in the header dumps are irrelevant because the count is 0 . Generally those would be the start of data . )

If the list is enclosed , the only thing nonzero is the item bit count which is vestigial and shares the 3rd header cell with refCount .

Code: Select all

  ` a 1234567 _take enc 0 _take DMP
00195750 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 .......... .....
00195760 4B 08 AA 8D 00 00 00 00 65 14 3F EA 8E 25 00 00 K.......e.?..%..


I wanted to check for certain that everything was being cleaned up properly so I executed with tracking of allocates & frees :

Code: Select all

  AF1  ` a 1234567 _take  0 _take   AF0 
  AF> +-splt
(
 9463552 50999328 9463552
 -9463552 -50999328
 )


And with the enclose :

Code: Select all

  AF1  ` a 1234567 _take enc  0 _take   AF0 
  AF> +-splt
(
 13089800 51048480 13089800 12785368
 -13089800 -51048480 -13089800
 )

So it all looks clean .